[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1346837209.2600.14.camel@twins>
Date: Wed, 05 Sep 2012 11:26:49 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Glauber Costa <glommer@...allels.com>
Cc: Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, linux-mm@...ck.org, davej@...hat.com,
ben@...adent.org.uk, pjt@...gle.com, lennart@...ttering.net,
kay.sievers@...y.org
Subject: Re: [RFC 0/5] forced comounts for cgroups.
On Wed, 2012-09-05 at 13:12 +0400, Glauber Costa wrote:
> On 09/05/2012 01:11 PM, Tejun Heo wrote:
> > Hello, Peter.
> >
> > On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> >> *confused* I always thought that was exactly what you meant with unified
> >> hierarchy.
> >
> > No, I never counted out differing granularity.
> >
>
> Can you elaborate on which interface do you envision to make it work?
> They will clearly be mounted in the same hierarchy, or as said
> alternatively, comounted.
>
> If you can turn them on/off on a per-subtree basis, which interface
> exactly do you propose for that?
I wouldn't, screw that. That would result in the exact same problem
we're trying to fix. I want a single hierarchy walk, that's expensive
enough.
> Would a pair of cgroup core files like available_controllers and
> current_controllers are a lot of drivers do, suffice?
No.. its not a 'feature' I care to support for 'my' controllers.
I simply don't want to have to do two (or more) hierarchy walks for
accounting on every schedule event, all that pointer chasing is stupidly
expensive.
--
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