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

[Umut Tezduyar Lindskog]

On Thu, May 22, 2014 at 2:14 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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).

But less cache misses (assuming cache is after mmu).

>
> 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.

I am proposing to dynamically tell kernel what to favor more if the
service really doesn't care about its start up order. And the way we
tell kernel what to favor more is through the cpu shares, just like
StartupCPUShare option.

Umut

>
> Lennart
>
> --
> Lennart Poettering, Red Hat