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

[Umut Tezduyar Lindskog]

On Wed, May 21, 2014 at 10:42 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 20.05.14 15:16, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:
>
>> > Wouldn't this be solved by telling the kernel to schedule the starting
>> > services with high latency (or whatever the terminology is), i.e.,
>> > give each of them a relatively large timeslice. That would decrease
>> > the flushing, but at the same time avoid any issues with deadlocks
>> > etc. It should also give us the flexibility to give some services low
>> > latency if that is required for them etc (think udev/systemd/dbus and
>> > otherthings which would otherwise block boot).
>>
>> This is exactly what the cpu.shares cgroup property does and that is
>> what the patch posted on ML is trying to utilize. In theory we should
>> be able to prioritize certain services with the posted patch. But the
>> frequent context switching problem still remains for non prioritized
>> services.
>>
>> I am having another thought about this and I might have something else
>> here. I am getting inspired by the posted patch and proposing
>> something like: "StartupCPUShares=*" (or any other symbol)
>>
>> What StartupCPUShares=* will tell systemd that the service really
>> doesn't care about it's cpu.shares value. If we have 100 services with
>> StartupCPUShares=* value, then with combination of some kind of
>> NumberOfActiveServices value, systemd will adjust cpu.shares of
>> NumberOfActiveServices until they are activated. Hope it makes sense.
>>
>> Thoughts?
>
> 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.

What I am proposing goes side by side with current StartupCPUShares
patch. It might be easier to visualize what I am proposing with a
diagram. I have shared this
https://docs.google.com/drawings/d/1224tBuCGgkDCT8Vc8x8-f2EUYP5sIgdROMXuEE7Snac/edit?usp=sharing,
let me know if it is a bit more clear.

Umut

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