[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111213190642.GB2421@somewhere.redhat.com>
Date: Tue, 13 Dec 2011 20:06:46 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Paul Menage <paul@...lmenage.org>,
Li Zefan <lizf@...fujitsu.com>,
Johannes Weiner <hannes@...xchg.org>,
Aditya Kali <adityakali@...gle.com>,
Oleg Nesterov <oleg@...hat.com>,
Kay Sievers <kay.sievers@...y.org>,
Tim Hockin <thockin@...kin.org>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH 00/10] cgroups: Task counter subsystem v6
On Tue, Dec 13, 2011 at 07:58:48AM -0800, Tejun Heo wrote:
> Hello, Frederic.
>
> Can you please rebase the patchset on top of cgroup/for-3.3?
Sure. But please note its fate is still under discussion. Whether
we want it upstream is still a running debate. But I certainly
need to rebase against your tree.
> I primarily like the idea of being able to track process usage w/ cgroup
> and enforce limits on it but hope that it could somehow integrate w/
> cgroup freezer. ie. trigger freezer if it goes over limit and let the
> userland tool / administrator deal with the frozen cgroup. I'm
> planning on extending cgroup freezer such that it supports recursive
> freezing and killing of frozen tasks. If we can fit task counters
> into that, we'll have general method of handling problematic cgroups -
> freeze, notify userland and let it deal with it.
Hmm, so you suggest a kernel trigger that freeze the cgroup when the
task limit is reached?
What about rather implementing register_event() for the tasks.usage such
that the user can be notified using eventfd when the limit is reached.
Then it would be up to the user to decide to freeze or any other thing.
Sounds like a more generic solution.
Hm?
Thanks.
--
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