[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim3g4uOJxUzRJqQ67zf-iZ2MXVib0JW3=zLBKGg@mail.gmail.com>
Date: Fri, 19 Nov 2010 12:38:09 -0800
From: Paul Menage <menage@...gle.com>
To: Ben Gamari <bgamari.foss@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>, 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, Nov 19, 2010 at 11:12 AM, Ben Gamari <bgamari.foss@...il.com> wrote:
> 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?
Backwards-compatibility with cpusets, which is what cgroups evolved from.
A delete_on_release option would be possible too, for the cases where
there's really no entity that wants to do more than simply delete the
group in question.
Paul
--
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