[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mxp53z72.fsf@gmail.com>
Date: Fri, 19 Nov 2010 14:12:17 -0500
From: Ben Gamari <bgamari.foss@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>
Cc: mzxreary@...inter.de, tytso@....edu, a.p.zijlstra@...llo.nl,
debiandev@...il.com, alan@...rguk.ukuu.org.uk,
dhaval.giani@...il.com, efault@....de, vgoyal@...hat.com,
oleg@...hat.com, markus@...ppelsdorf.de,
mathieu.desnoyers@...icios.com, mingo@...e.hu,
linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups
On Fri, 19 Nov 2010 09:51:14 -0800, Linus Torvalds <torvalds@...ux-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?
I guess it's a little too late at this point considering the old
mechanism will still need to be supported, but it seems like this would
provide a slightly cheaper cleanup path. Just my (perhaps flawed) two
pence.
>
> So guys, calm down. We don't need to hate each other.
>
Thanks for the nudge back to sanity.
Cheers,
- Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists