Hello, On Mon, Jun 24, 2013 at 02:39:53PM +0100, Daniel P. Berrange wrote: > On Mon, Jun 24, 2013 at 03:27:15PM +0200, Lennart Poettering wrote: > > On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote: > > > > > 1. I put all the entire world into a separate, highly constrained > > > cgroup. My real-time code runs outside that cgroup. This seems to > > > exactly what slices are for, but I need kernel threads to go in to > > > the constrained cgroup. Will systemd support this? > > > > I am not sure whether the ability to move kernel threads into cgroups > > will stay around at all, from the kernel side. Tejun, can you comment > > on this? > > KVM uses the vhost_net device for accelerating guest network I/O > paths. This device creates a new kernel thread on each open(), > and that kernel thread is attached to the cgroup associated > with the process that open()d the device. > > If systemd allows for a process to be moved between cgroups, then > it must also be capable of moving any associated kernel threads to > the new cgroup at the same time. This co-placement of vhost-net > threads with the KVM process, is very critical for I/O performance > of KVM networking.
Yeah, the way virt drivers use cgroups right now is pretty hacky. I was thinking about adding per-process workqueue which follows the cgroup association of the process after the unified hierarchy and then convert virt to use that. At any rate, those kthreads can be moved via cgroup.procs, so unified hierarchy wouldn't break it from kernel side. Not sure how the interface would look from systemd side tho. Thanks. -- tejun _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
