Messages in this thread | | | Date | Sat, 20 Nov 2010 02:13:30 +0100 | From | Lennart Poettering <> | Subject | Re: [RFC/RFT PATCH v3] sched: automated per tty task groups |
| |
On Fri, 19.11.10 14:12, Ben Gamari (bgamari.foss@gmail.com) wrote:
> > On Fri, 19 Nov 2010 09:51:14 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > And the user level approach? I think it's fine too. If you run systemd > > for other reasons (or if the gnome people add it to the task launcher > > or whatever), doing it there isn't wrong. I personally think it's > > somewhat disgusting to have a user-level callback with processes etc > > just to clean up a group, but whatever. As long as it's not common, > > who cares? > > > On that note, is there a good reason why the notify_on_release interface > works the way it does? Wouldn't it be simpler if the cgroup simply > provided a file on which a process (e.g. systemd) could block?
The notify_on_release interface is awful indeed. Feels like the old hotplug interface where each module request by the kernel caused a hotplug script to be spawned by the kernel.
However, I am not sure I like the idea of having pollable files like that, because in the systemd case I am very much interested in getting recursive notifications, i.e. I want to register once for getting notifications for a full subtree instead of having to register for each cgroup individually.
My personal favourite solution would be to get a netlink msg when a cgroup runs empty. That way multiple programs could listen to the events at the same time, and we'd have an easy way to subscribe to a whole hierarchy of groups.
Lennart
-- Lennart Poettering - Red Hat, Inc.
| |