[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130604205426.GI14916@htj.dyndns.org>
Date: Tue, 4 Jun 2013 13:54:26 -0700
From: Tejun Heo <tj@...nel.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-mm@...ck.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, Ying Han <yinghan@...gle.com>,
Hugh Dickins <hughd@...gle.com>,
Glauber Costa <glommer@...allels.com>,
Michel Lespinasse <walken@...gle.com>,
Greg Thelen <gthelen@...gle.com>,
Balbir Singh <bsingharora@...il.com>
Subject: Re: [patch -v4 4/8] memcg: enhance memcg iterator to support
predicates
Hey,
On Tue, Jun 04, 2013 at 10:48:07PM +0200, Michal Hocko wrote:
> > I really don't think memcg can afford to add more mess than there
> > already is. Let's try to get things right with each change, please.
>
> Is this really about inside vs. outside skipping? I think this is a
> general improvement to the code. I really prefer not duplicating common
> code and skipping handling is such a code (we have a visitor which can
> control the walk). With a side bonus that it doesn't have to pollute
> vmscan more than necessary.
>
> Please be more specific about _what_ is so ugly about this interface so
> that it matters so much.
Can you please try the other approach and see how it looks? It's just
my general experience that you usually end up with something much
uglier when you try to do much inside an iterator and having to add
callbacks which need to communicate through enums is usually a pretty
good sign that it took a wrong turn somewhere. There sure are cases
where such approach is necessary but I really don't see it here. So,
it'd be really great if you can give a shot.
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