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

[Lennart Poettering]

On Wed, 21.05.14 13:52, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> > Not following here... Aren't you describing a best-effort system here?
> > But the CPUShares= stuff is best-effort stuff anyway, and just tells the
> > kernel what is more important thant other stuff. Or, to turn this
> > around, where would the difference be between the system you describe
> > and one where the unimportant services just set StartupCPuShares= to
> > some very low value?
> 
> Thanks for looking at this.
> 
> Sole problem is due to the fact that we have too many services in
> running state in the scheduler's run queue. Changing the manager's run
> queue from list to priority queue by itself, as far as I can see, will
> not change anything because programs are still going to be in
> activating state.
> 
> 100 "Unimportant" jobs setting their StartupCPUShares= to same some
> low value is no different either because 100 of them are going to be
> in "running" state, in scheduler run queue, causing frequent context
> switches.

Well, as soon as you have more than one process you will get those
context switches no matter what. I mean, if you have a fixed amount of
things to do, then whether you run six processes, A, B, C, D, E, F in
parallel or just two of them at a time doesn't have any effect on the
number of context switches (assuming all have the same prio), since
scheduling 
           
           A→B→C→D→E→F→A→B→C→D→E→F→... or 
           A→B→A→B→...→C→D→C→D→...→E→F→E→F→...

will result in the same number of "→" (which shall indicate context
switches here).

If you want to do the same work with fewer context switches, then you
either have to make sure only a *single* process is runnable at any time
(which is illusionary), or you just lower your HZ value to make sure the
kernel simpy reschedules less often...

Hence, still, I am not sure I grok what you are proposing and in which
way that would not be second guessing the kernel scheduler at something
the kernel scheduler should be much better at than us.

Lennart

-- 
Lennart Poettering, Red Hat