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

[Lennart Poettering]

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?

Lennart

-- 
Lennart Poettering, Red Hat