Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

[Balbir Singh]

* Lennart Poettering <mzxreary@xxxxxxxxxxx> [2010-11-20 02:13:30]:

> On Fri, 19.11.10 14:12, Ben Gamari (bgamari.foss@xxxxxxxxx) wrote:
> 
> > 
> > On Fri, 19 Nov 2010 09:51:14 -0800, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
>

The netlink message should not be hard to do if we agree to work on
it. The largest objections I've heard is that netlink implies
network programming and most users want to be able to script in
their automation and network scripting is hard.

-- 
	Three Cheers,
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/