From: Frederic Weisbecker <fweisbec@gmail.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Paul Menage <menage@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 0/4] cgroups: Start a basic rlimit subsystem
Date: Mon, 20 Jun 2011 21:11:33 +0200 [thread overview]
Message-ID: <20110620191126.GB1613@somewhere> (raw)
In-Reply-To: <4DFEE9BE.6050501@cn.fujitsu.com>
On Mon, Jun 20, 2011 at 02:33:34PM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > This starts a basic rlimit cgroup subsystem with only the
> > equivalent of RLIMIT_NPROC yet. This can be useful to limit
> > the global effects of a local fork bomb for example (local
> > in term of a cgroup).
> >
> > The thing is further expandable to host more general resource
> > limitations in the scope of a cgroup.
> >
>
> As this subsystem is named "rlimit", I think we should have a bigger
> picture about how this subsystem will be.
>
> For example, which of other RLIMIT_XXX can be make cgroup-aware in
> a meaningful way and which can't.
>
> Another issue is, we can apply the limit of RLIMIT_NPROC as the sum
> of the tasks' limit in a cgroup, but some other RLIMIT_XXX can't
> work in this way. Take RLIMIT_NICE for example, we can apply this
> limit to each of the tasks in the cgroup.
Looking at the other rlimit options, it seems all of them can be applied
to a cgroup. They just won't all be implemented the same way.
Those that count and limit a global user resource, like NPROC, can be
implemented using the res_counter charge/uncharge that propagate the
resource consuming to the parent cgroups.
Other rlimits that are traditionally only process wide can be implemented
here as a simple limit applied to all processes in the whole cgroup.
For example RLIMIT_CORE would be a limit in any core dump on
the whole cgroup.
RLIMIT_NOFILE would be a limit on the number of files opened by the whole
cgroup.
etc...
I think they all need to be treated case by case when/if users come and propose
more rlimit options. These don't all necessary need to mirror the setrlimit
options. We could pick existing ones but change a bit their semantics to fit
more into the cgroups meaning (as a general rule any rlimit.* file must be a
cgroup wide limitation), or create new rlimit options if specific needs arise.
There can be another kind of rlimit options that can be cgroup wide but apply
per process, in which case we should tweak a bit the name of the rlimit option file.
Consider RLIMIT_STACK for example.
If we want a cgroup option that applies to the total of stack used by the whole
cgroup, the file name would be rlim.stack. If we want that limitation to happen
to the whole cgroup but per process, it would be rlim.stack_per_process.
next prev parent reply other threads:[~2011-06-20 19:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 23:51 [RFC PATCH 0/4] cgroups: Start a basic rlimit subsystem Frederic Weisbecker
2011-06-19 23:51 ` [RFC PATCH 1/4] cgroups: Allow a cgroup subsys to reject a fork Frederic Weisbecker
2011-06-21 17:39 ` Paul Menage
2011-06-23 13:38 ` Frederic Weisbecker
2011-06-19 23:51 ` [RFC PATCH 2/4] cgroups: Add res_counter_write_u64() API Frederic Weisbecker
2011-06-19 23:51 ` [RFC PATCH 3/4] cgroups: New resource counter inheritance API Frederic Weisbecker
2011-06-19 23:51 ` [RFC PATCH 4/4] cgroups: Add an rlimit subsystem Frederic Weisbecker
2011-06-21 17:37 ` Paul Menage
2011-06-23 13:48 ` Frederic Weisbecker
2011-06-24 22:22 ` Paul Menage
2011-06-28 17:37 ` Aditya Kali
2011-07-06 0:21 ` Frederic Weisbecker
2011-06-28 18:08 ` Aditya Kali
2011-07-06 0:43 ` Frederic Weisbecker
2011-06-20 6:33 ` [RFC PATCH 0/4] cgroups: Start a basic " Li Zefan
2011-06-20 19:11 ` Frederic Weisbecker [this message]
2011-06-21 8:09 ` Li Zefan
2011-06-21 16:18 ` Frederic Weisbecker
2011-06-21 17:08 ` Paul Menage
2011-06-23 13:30 ` Frederic Weisbecker
2011-06-24 22:18 ` Paul Menage
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=20110620191126.GB1613@somewhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
/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