Hi, On Wed, May 21, 2014 at 10:44 PM, Uoti Urpala <uoti.urp...@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 <t...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
