linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, Ying Han <yinghan@google.com>,
	Hugh Dickins <hughd@google.com>,
	Glauber Costa <glommer@parallels.com>,
	Michel Lespinasse <walken@google.com>,
	Greg Thelen <gthelen@google.com>,
	Balbir Singh <bsingharora@gmail.com>
Subject: Re: [patch -v4 4/8] memcg: enhance memcg iterator to support predicates
Date: Tue, 4 Jun 2013 13:54:26 -0700	[thread overview]
Message-ID: <20130604205426.GI14916@htj.dyndns.org> (raw)
In-Reply-To: <20130604204807.GA13231@dhcp22.suse.cz>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-06-04 20:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 10:18 [patch v4] Soft limit rework Michal Hocko
2013-06-03 10:18 ` [patch -v4 1/8] memcg: integrate soft reclaim tighter with zone shrinking code Michal Hocko
2013-06-03 10:18 ` [patch -v4 2/8] memcg: Get rid of soft-limit tree infrastructure Michal Hocko
2013-06-03 10:18 ` [patch -v4 3/8] vmscan, memcg: Do softlimit reclaim also for targeted reclaim Michal Hocko
2013-06-03 10:18 ` [patch -v4 4/8] memcg: enhance memcg iterator to support predicates Michal Hocko
2013-06-04  1:07   ` Tejun Heo
2013-06-04 13:45     ` Michal Hocko
2013-06-04 19:36       ` Tejun Heo
2013-06-04 20:48         ` Michal Hocko
2013-06-04 20:54           ` Tejun Heo [this message]
2013-06-05  7:37             ` Michal Hocko
2013-06-05  8:05               ` Tejun Heo
2013-06-05  8:52                 ` Michal Hocko
2013-06-05  8:58                   ` Tejun Heo
2013-06-05  9:07                     ` Michal Hocko
2013-06-05  9:09                       ` Tejun Heo
2013-06-07  0:48                         ` Tejun Heo
2013-06-07  8:25                           ` Michal Hocko
2013-06-10  7:48   ` Michal Hocko
2013-06-03 10:18 ` [patch -v4 5/8] memcg: track children in soft limit excess to improve soft limit Michal Hocko
2013-06-03 10:18 ` [patch -v4 6/8] memcg, vmscan: Do not attempt soft limit reclaim if it would not scan anything Michal Hocko
2013-06-03 10:18 ` [patch -v4 7/8] memcg: Track all children over limit in the root Michal Hocko
2013-06-03 10:18 ` [patch -v4 8/8] memcg, vmscan: do not fall into reclaim-all pass too quickly Michal Hocko
2013-06-04 16:27 ` [patch v4] Soft limit rework Balbir Singh
2013-06-04 16:38   ` Michal Hocko
2013-06-04 17:57     ` Balbir Singh
2013-06-04 18:08       ` Michal Hocko
2013-06-11 15:43 ` Michal Hocko
2013-06-17 14:01   ` Michal Hocko

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=20130604205426.GI14916@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=glommer@parallels.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=walken@google.com \
    --cc=yinghan@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;
as well as URLs for NNTP newsgroup(s).