From: Hugh Dickins <hughd@google.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
Balbir Singh <bsingharora@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
linux-mm@kvack.org
Subject: Re: [PATCH 3/5] memcg: lru_size instead of MEM_CGROUP_ZSTAT
Date: Thu, 5 Jan 2012 12:14:25 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.00.1201051139140.2009@eggly.anvils> (raw)
In-Reply-To: <20120105153344.8c6682fb.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 5 Jan 2012, KAMEZAWA Hiroyuki wrote:
> On Sat, 31 Dec 2011 23:30:38 -0800 (PST)
> Hugh Dickins <hughd@google.com> wrote:
>
> > I never understood why we need a MEM_CGROUP_ZSTAT(mz, idx) macro
> > to obscure the LRU counts. For easier searching? So call it
> > lru_size rather than bare count (lru_length sounds better, but
> > would be wrong, since each huge page raises lru_size hugely).
> >
> > Signed-off-by: Hugh Dickins <hughd@google.com>
>
>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Thanks (to you and the other guys) for all the acks.
>
> BTW, can this counter be moved to lruvec finally ?
Well. It could be, but I haven't moved it (even in coming patches),
and it's not yet quite clear to me whether that's right or not.
Because there's a struct lruvec in struct zone, which we use when
!CONFIG_CGROUP_MEM_RES_CTLR or when mem_cgroup_disabled(); but the
corresponding lru_sizes would be a waste in those cases, because
they then just duplicate vm_stat[NR_INACTIVE_ANON..NR_UNEVICTABLE].
And we want to keep vm_stat[NR_INACTIVE_ANON..NR_UNEVICTABLE],
because we do want those global LRU sizes even in the memcg case.
Of course, we could put unused lru_size fields in anyway, it would
not waste much space.
But I'd prefer to hold off for now: I imagine that we're moving
towards a future in which even !CONFIG_CGROUP_MEM_RES_CTLR will have a
root_mem_cgroup, and it will become clearer what to place where then.
We use the lruvec heavily in the per-memcg per-zone locking patches,
as something low-level code can operate on without needing to know
if it's memcg or global; but have not actually needed to move the
lru_sizes into the structure (perhaps it's a hack: there is one place
I use container_of to go from the lruvec pointer to the lru_sizes).
(I might want to move the reclaim_stat into the lruvec, don't know
yet: I only just noticed that there are places where I'm not locking
the reclaim_stat properly: it's not such a big deal that it was ever
obvious, but I ought to get it right.)
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-01-05 20:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-01 7:26 [PATCH 0/5] memcg: trivial cleanups Hugh Dickins
2012-01-01 7:27 ` [PATCH 1/5] memcg: replace MEM_CONT by MEM_RES_CTLR Hugh Dickins
2012-01-01 7:33 ` KOSAKI Motohiro
2012-01-02 11:53 ` Michal Hocko
2012-01-05 6:30 ` KAMEZAWA Hiroyuki
2012-01-01 7:29 ` [PATCH 2/5] memcg: replace mem and mem_cont stragglers Hugh Dickins
2012-01-01 7:34 ` KOSAKI Motohiro
2012-01-02 12:25 ` Michal Hocko
2012-01-05 6:31 ` KAMEZAWA Hiroyuki
2012-01-01 7:30 ` [PATCH 3/5] memcg: lru_size instead of MEM_CGROUP_ZSTAT Hugh Dickins
2012-01-01 7:37 ` KOSAKI Motohiro
2012-01-02 12:59 ` Michal Hocko
2012-01-02 19:43 ` Hugh Dickins
2012-01-03 11:05 ` Michal Hocko
2012-01-05 6:33 ` KAMEZAWA Hiroyuki
2012-01-05 20:14 ` Hugh Dickins [this message]
2012-01-01 7:31 ` [PATCH 4/5] memcg: enum lru_list lru Hugh Dickins
2012-01-01 7:38 ` KOSAKI Motohiro
2012-01-02 13:01 ` Michal Hocko
2012-01-05 6:34 ` KAMEZAWA Hiroyuki
2012-01-01 7:33 ` [PATCH 5/5] memcg: remove redundant returns Hugh Dickins
2012-01-01 7:38 ` KOSAKI Motohiro
2012-01-02 13:03 ` Michal Hocko
2012-01-05 6:35 ` KAMEZAWA Hiroyuki
2012-01-01 17:01 ` [PATCH 0/5] memcg: trivial cleanups Kirill A. Shutemov
2012-01-09 13:03 ` Johannes Weiner
2012-01-15 0:07 ` Hugh Dickins
2012-01-15 0:09 ` [PATCH 1/5] memcg: replace MEM_CONT by MEM_RES_CTLR Hugh Dickins
2012-01-15 0:10 ` [PATCH 2/5] memcg: replace mem and mem_cont stragglers Hugh Dickins
2012-01-15 0:12 ` [PATCH 3/5] memcg: lru_size instead of MEM_CGROUP_ZSTAT Hugh Dickins
2012-01-15 0:13 ` [PATCH 4/5] memcg: enum lru_list lru Hugh Dickins
2012-01-15 0:14 ` [PATCH 5/5] memcg: remove redundant returns Hugh Dickins
2012-01-16 9:47 ` [PATCH 0/5] memcg: trivial cleanups 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=alpine.LSU.2.00.1201051139140.2009@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--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