From: Frederic Weisbecker <fweisbec@gmail.com>
To: Aditya Kali <adityakali@google.com>
Cc: linux-kernel@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 4/4] cgroups: Add an rlimit subsystem
Date: Wed, 6 Jul 2011 02:21:45 +0200 [thread overview]
Message-ID: <20110706002142.GA10010@somewhere.redhat.com> (raw)
In-Reply-To: <loom.20110628T193035-346@post.gmane.org>
Please keep the Cc list, everybody may has missed your message. I just found
it while browsing randomly my lkml INBOX.
On Tue, Jun 28, 2011 at 05:37:17PM +0000, Aditya Kali wrote:
> Paul Menage <menage <at> google.com> writes:
> > What we need is a res_counter_move_charge(A, B, amount) function which will:
> >
> > - locate C, the nearest common ancestor of A and B
> > - lock up the chain from B up to but not including C, adding the new charge
> > - unlock up the chain from B to C
> > - uncharge along the chain from A up to but not including C (not sure
> > how much locking is needed there since there's no need for roll back).
> >
> > Paul
> >
>
> Another alternative is to use the 'attach' callback in struct cgroup_subsys which
> gets both the old cgroup and the new cgroup as parameters and do
> rlim_remove_proc(old_cgrp) and res_counter_charge(new_cgrp) in this same
> function under the protection of a spinlock.
> It would be good to add a return value to the 'attach' callback too.
But the it would require a global lock, or a per hierarchy one, if you want
to protect against forks and exits. And that wouldn't scale due to these fork/exit
that would take that big lock.
next prev parent reply other threads:[~2011-07-06 0:21 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 [this message]
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
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=20110706002142.GA10010@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=adityakali@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.