[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120926193417.GJ12544@google.com>
Date: Wed, 26 Sep 2012 12:34:17 -0700
From: Tejun Heo <tj@...nel.org>
To: Glauber Costa <glommer@...allels.com>
Cc: Michal Hocko <mhocko@...e.cz>, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, kamezawa.hiroyu@...fujitsu.com,
devel@...nvz.org, linux-mm@...ck.org,
Suleiman Souhlal <suleiman@...gle.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Mel Gorman <mgorman@...e.de>,
David Rientjes <rientjes@...gle.com>,
Johannes Weiner <hannes@...xchg.org>
Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure
Hello,
On Wed, Sep 26, 2012 at 10:56:09PM +0400, Glauber Costa wrote:
> For me, it is the other way around: it makes perfect sense to have a
> per-subtree selection of features where it doesn't hurt us, provided it
> is hierarchical. For the mere fact that not every application is
> interested in this (Michal is the one that is being so far more vocal
> about this not being needed in some use cases), and it is perfectly
> valid to imagine such applications would coexist.
>
> So given the flexibility it brings, the real question is, as I said,
> backwards: what is it necessary to make it a global switch ?
Because it hurts my head and it's better to keep things simple. We're
planning to retire .use_hierarhcy in sub hierarchies and I'd really
like to prevent another fiasco like that unless there absolutely is no
way around it. Flexibility where necessary is fine but let's please
try our best to avoid over-designing things. We've been far too good
at getting lost in flexbility maze. Michal, care to chime in?
Thanks.
--
tejun
--
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