From: Tejun Heo <tj@kernel.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Paul Menage <paul@paulmenage.org>, Li Zefan <lizf@cn.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Aditya Kali <adityakali@google.com>,
Oleg Nesterov <oleg@redhat.com>,
Kay Sievers <kay.sievers@vrfy.org>,
Tim Hockin <thockin@hockin.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH 00/10] cgroups: Task counter subsystem v6
Date: Tue, 13 Dec 2011 12:49:18 -0800 [thread overview]
Message-ID: <20111213204918.GK25802@google.com> (raw)
In-Reply-To: <20111213190642.GB2421@somewhere.redhat.com>
Hello,
On Tue, Dec 13, 2011 at 08:06:46PM +0100, Frederic Weisbecker wrote:
> On Tue, Dec 13, 2011 at 07:58:48AM -0800, Tejun Heo wrote:
> > 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 see.
> > 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?
Yeah, something like that. I'm not really sure about how it would
actually work tho.
> 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.
Maybe, the problem would be how to ensure that the userland manager
can respond fast enough (whatever that means...).
Thanks.
--
tejun
next prev parent reply other threads:[~2011-12-13 20:49 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 19:07 [PATCH 00/10] cgroups: Task counter subsystem v6 Frederic Weisbecker
2011-10-03 19:07 ` [PATCH 01/10] cgroups: Add res_counter_write_u64() API Frederic Weisbecker
2011-10-04 0:17 ` Kirill A. Shutemov
2011-10-11 13:44 ` Frederic Weisbecker
2011-10-03 19:07 ` [PATCH 02/10] cgroups: New resource counter inheritance API Frederic Weisbecker
2011-10-04 0:20 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 03/10] cgroups: Add previous cgroup in can_attach_task/attach_task callbacks Frederic Weisbecker
2011-10-04 0:22 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 04/10] cgroups: New cancel_attach_task subsystem callback Frederic Weisbecker
2011-10-04 0:27 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 05/10] cgroups: Ability to stop res charge propagation on bounded ancestor Frederic Weisbecker
2011-10-04 0:41 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 06/10] cgroups: Add res counter common ancestor searching Frederic Weisbecker
2011-10-03 19:07 ` [PATCH 07/10] res_counter: Allow charge failure pointer to be null Frederic Weisbecker
2011-10-04 1:30 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 08/10] cgroups: Pull up res counter charge failure interpretation to caller Frederic Weisbecker
2011-10-04 1:32 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 09/10] cgroups: Allow subsystems to cancel a fork Frederic Weisbecker
2011-10-04 1:38 ` Kirill A. Shutemov
2011-10-03 19:07 ` [PATCH 10/10] cgroups: Add a task counter subsystem Frederic Weisbecker
2011-10-06 9:23 ` Kirill A. Shutemov
2011-10-11 13:41 ` Frederic Weisbecker
2011-10-04 22:01 ` [PATCH 00/10] cgroups: Task counter subsystem v6 Andrew Morton
2011-10-11 13:40 ` Frederic Weisbecker
2011-10-25 20:06 ` Tim Hockin
2011-10-28 23:30 ` Andrew Morton
2011-10-29 9:38 ` Glauber Costa
2011-11-03 16:49 ` Frederic Weisbecker
2011-11-03 16:58 ` Glauber Costa
2011-11-03 17:02 ` Paul Menage
2011-11-03 17:06 ` Glauber Costa
2011-11-03 17:28 ` Paul Menage
2011-11-03 17:35 ` Glauber Costa
2011-11-03 17:56 ` Paul Menage
2011-11-04 13:17 ` Glauber Costa
2011-11-03 17:00 ` Frederic Weisbecker
2011-11-04 2:57 ` Li Zefan
2011-11-04 12:37 ` Frederic Weisbecker
2011-10-06 6:51 ` Li Zefan
2011-10-11 13:41 ` Frederic Weisbecker
2011-12-13 15:58 ` Tejun Heo
2011-12-13 19:06 ` Frederic Weisbecker
2011-12-13 20:49 ` Tejun Heo [this message]
2011-12-14 15:07 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111213204918.GK25802@google.com \
--to=tj@kernel.org \
--cc=adityakali@google.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=kay.sievers@vrfy.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=oleg@redhat.com \
--cc=paul@paulmenage.org \
--cc=thockin@hockin.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).