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

[Umut Tezduyar Lindskog]

Hi,

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:
>> On Tue, May 20, 2014 at 1:46 PM, Tom Gundersen <teg at jklm.no> 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.
>
> 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.

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

Umut

>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel