[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EAF4B16.6030505@cn.fujitsu.com>
Date: Tue, 01 Nov 2011 09:27:50 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Lennart Poettering <mzxreary@...inter.de>
CC: Frederic Weisbecker <fweisbec@...il.com>,
Paul Menage <paul@...lmenage.org>,
Kay Sievers <kay.sievers@...y.org>,
linux-kernel@...r.kernel.org, harald@...hat.com, david@...ar.dk,
greg@...ah.com
Subject: Re: A Plumber’s Wish List for Linux
Lennart Poettering wrote:
> On Tue, 25.10.11 13:40, Li Zefan (lizf@...fujitsu.com) wrote:
>
>>> cgroups provides us with all of that, though the last two items only in
>>> a suboptimal way: notification of cgroups running empty is ugly, since
>>> it is done by spawning a usermode helper (we'd prefer a netlink msg or
>>> so), and the process killing is a bit racy.
>>
>> How about using eventfd? You can create an eventfd for the specific "tasks"
>> file, and when the cgroup gets empty (no task in it), you'll get a notification.
>>
>> It should be easy to implement, since cgroup already supports eventfd-based
>> API.
>
> I am quite convinced that using eventfd() like this is quite ugly. The
> current evetnfd() logic is not recursive anyway, hence wouldn't help us
> much.
>
I remember in an earlier email you stated you want to be able to kill all tasks
in a cgroup and its children, and you used the word "recursive", but what do you
mean by ""recursive" for empty cgroup notification, do you expect the listener
to recieve a message if a cgroup or any of its children becomes empty?
--
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