[systemd-devel] Start-up resource and prioritization control

[Uoti Urpala]

On Thu, 2014-05-22 at 08:40 +0200, Umut Tezduyar Lindskog wrote:
> On Wed, May 21, 2014 at 10:44 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > On Tue, 2014-05-20 at 15:16 +0200, Umut Tezduyar Lindskog wrote:
> >> This is exactly what the cpu.shares cgroup property does and that is
> >> what the patch posted on ML is trying to utilize.
> >
> > I don't think they are the same. If I understood correctly, the patch
> > was about setting priorities. Latency is a different thing.
> 
> Tom has explained what he meant with "latency" as large time slice
> (tom: i.e., give each of them a relatively large timeslice). Giving
> large time slice is exactly what the mentioned patch is doing.
> Indirectly, changing the priority of some services.

No, they are not the same. One is about picking the running task among a
smaller set of services. The other is about changing the running task
less often.


> > Your problem was context switch overhead. That can be fixed by making
> > the kernel switch tasks less often - even if there are 100 runnable
> > tasks, if the kernel keeps running each task for a second before
> > switching to the next one, context switch overhead will not be large.
> 
> Investigating various tick interrupt frequency is another option but I
> rather not go that route before exhausting other possibilities since
> it will affect the entire system, especially RT jobs.

Tick interrupt is a different thing - context switches are not timed
with anything like "switch at each tick" IIRC. Changing the default time
slice length need not affect realtime tasks; as soon as a high-priority
RT task becomes runnable, the scheduler can still immediately switch to
that, no matter how long the default time slices are. Also, if changing
scheduler parameters systemwide does cause some other problem, then you
could change them back after startup has finished (instead of changing
task priorities).