From: Hugh Dickins <hughd@google.com>
To: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] mm/memcg: apply add/del_page to lruvec
Date: Mon, 14 May 2012 13:02:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.00.1205141252060.1693@eggly.anvils> (raw)
In-Reply-To: <4FB0E985.9000107@openvz.org>
On Mon, 14 May 2012, Konstantin Khlebnikov wrote:
> Hugh Dickins wrote:
> > Take lruvec further: pass it instead of zone to add_page_to_lru_list()
> > and del_page_from_lru_list(); and pagevec_lru_move_fn() pass lruvec
> > down to its target functions.
> >
> > This cleanup eliminates a swathe of cruft in memcontrol.c,
> > including mem_cgroup_lru_add_list(), mem_cgroup_lru_del_list() and
> > mem_cgroup_lru_move_lists() - which never actually touched the lists.
> >
> > In their place, mem_cgroup_page_lruvec() to decide the lruvec,
> > previously a side-effect of add, and mem_cgroup_update_lru_size()
> > to maintain the lru_size stats.
> >
> > Whilst these are simplifications in their own right, the goal is to
> > bring the evaluation of lruvec next to the spin_locking of the lrus,
> > in preparation for a future patch.
> >
> > Signed-off-by: Hugh Dickins<hughd@google.com>
> > ---
> > The horror, the horror: I have three lines of 81 columns:
> > I do think they look better this way than split up.
>
> This too huge and hard to review. =(
Hah, we have very different preferences: whereas I found your
split into twelve a hindrance to review rather than a help.
> I have the similar thing splitted into several patches.
I had been hoping to get this stage, where I think we're still in
agreement (except perhaps on the ordering of function arguments!),
into 3.5 as a basis for later discussion.
But I won't have time to split it into bite-sized pieces for
linux-next now before 3.4 goes out, so it sounds like we'll have
to drop it this time around. Oh well.
Thanks (you and Kame and Michal) for the very quick review of
the other, even more trivial, patches.
>
> Also I want to replace page_cgroup->mem_cgroup pointer with
> page_cgroup->lruvec
> and rework "surreptitious switching any uncharged page to root"
> In my set I have mem_cgroup_page_lruvec() without side-effects and
> mem_cgroup_page_lruvec_putback() with can switch page's lruvec, but it not
> always moves pages to root: in
> putback_inactive_pages()/move_active_pages_to_lru()
> we have better candidate for lruvec switching.
But those sound like later developments on top of this to me.
Hugh
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-14 20:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 4:58 [PATCH 0/3] mm/memcg: trivia and more lruvec Hugh Dickins
2012-05-14 5:00 ` [PATCH 1/3] mm/memcg: get_lru_size not get_lruvec_size Hugh Dickins
2012-05-14 10:34 ` KAMEZAWA Hiroyuki
2012-05-14 10:44 ` Konstantin Khlebnikov
2012-05-14 15:49 ` Michal Hocko
2012-05-14 5:01 ` [PATCH 2/3] mm: trivial cleanups in vmscan.c Hugh Dickins
2012-05-14 5:56 ` KOSAKI Motohiro
2012-05-14 10:36 ` KAMEZAWA Hiroyuki
2012-05-14 10:46 ` Konstantin Khlebnikov
2012-05-14 15:52 ` Michal Hocko
2012-05-14 5:02 ` [PATCH 3/3] mm/memcg: apply add/del_page to lruvec Hugh Dickins
2012-05-14 10:40 ` KAMEZAWA Hiroyuki
2012-05-14 11:16 ` Konstantin Khlebnikov
2012-05-14 20:02 ` Hugh Dickins [this message]
2012-05-15 8:53 ` Konstantin Khlebnikov
2012-05-15 20:53 ` Hugh Dickins
2012-05-14 16:39 ` Michal Hocko
2012-05-15 12:34 ` Michal Hocko
2012-05-30 22:17 ` baozich
2012-05-31 22:58 ` Hugh Dickins
2012-05-31 19:14 ` Chen Baozi
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=alpine.LSU.2.00.1205141252060.1693@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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