From: Johannes Weiner <jweiner@redhat.com>
To: Andrew Morton <akpm00@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
Balbir Singh <bsingharora@gmail.com>,
Ying Han <yinghan@google.com>, Greg Thelen <gthelen@google.com>,
Michel Lespinasse <walken@google.com>,
Rik van Riel <riel@redhat.com>,
Minchan Kim <minchan.kim@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 00/10] memcg naturalization -rc4
Date: Tue, 4 Oct 2011 09:47:23 +0200 [thread overview]
Message-ID: <20111004074723.GA13681@redhat.com> (raw)
In-Reply-To: <20111003161149.bc458294.akpm00@gmail.com>
On Mon, Oct 03, 2011 at 04:11:49PM -0700, Andrew Morton wrote:
> On Thu, 29 Sep 2011 23:00:54 +0200
> Johannes Weiner <jweiner@redhat.com> wrote:
>
> > this is the fourth revision of the memory cgroup naturalization
> > series.
>
> The patchset removes 20 lines from include/linux/*.h and removes
> exactly zero lines from mm/*.c. Freaky.
It adds 42 lines more comments than it deletes.
The diffstat looked better when this series included the soft limit
reclaim rework, which depends on global reclaim doing hierarchy walks.
I plan to do this next, it deletes ~500 lines.
> If we were ever brave/stupid emough to make
> CONFIG_CGROUP_MEM_RES_CTLR=y unconditional, how much could we simplify
> mm/?
There will always be a remaining part that is only of interest to
people with memory cgroups, but that doesn't mean we can't shrink this
part to an adequate size.
> We are adding bits of overhead to the CONFIG_CGROUP_MEM_RES_CTLR=n case
> all over the place. This patchset actually decreases the size of allnoconfig
> mm/built-in.o by 1/700th.
Most of the memcg code should be completely optimized away with =n,
except for some on-stack data structures that have a struct mem_cgroup
pointer.
In the meantime, major distros started to =y per default and people
are complaining that memcg functions show up in the profiles of their
non-memcg workload. This one worries me more.
> A "struct mem_cgroup" sometimes gets called "mem", sometimes "memcg",
> sometimes "mem_cont". Any more candidates? Is there any logic to
> this?
I used memcg throughout except for two patches that I fixed up. I
don't think there is any reason to keep them different, so I'll send a
fix to rename the remaining ones to memcg.
> Anyway... it all looks pretty sensible to me, but the timing (at
> -rc8!) is terrible. Please keep this material maintained for -rc1, OK?
Thanks, and yeah, the timing is ambitious, I hoped that the deferred
release and merge window could make it possible.
I'll keep it uptodate.
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <jweiner@redhat.com>
To: Andrew Morton <akpm00@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
Balbir Singh <bsingharora@gmail.com>,
Ying Han <yinghan@google.com>, Greg Thelen <gthelen@google.com>,
Michel Lespinasse <walken@google.com>,
Rik van Riel <riel@redhat.com>,
Minchan Kim <minchan.kim@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Hugh Dickins <hughd@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 00/10] memcg naturalization -rc4
Date: Tue, 4 Oct 2011 09:47:23 +0200 [thread overview]
Message-ID: <20111004074723.GA13681@redhat.com> (raw)
In-Reply-To: <20111003161149.bc458294.akpm00@gmail.com>
On Mon, Oct 03, 2011 at 04:11:49PM -0700, Andrew Morton wrote:
> On Thu, 29 Sep 2011 23:00:54 +0200
> Johannes Weiner <jweiner@redhat.com> wrote:
>
> > this is the fourth revision of the memory cgroup naturalization
> > series.
>
> The patchset removes 20 lines from include/linux/*.h and removes
> exactly zero lines from mm/*.c. Freaky.
It adds 42 lines more comments than it deletes.
The diffstat looked better when this series included the soft limit
reclaim rework, which depends on global reclaim doing hierarchy walks.
I plan to do this next, it deletes ~500 lines.
> If we were ever brave/stupid emough to make
> CONFIG_CGROUP_MEM_RES_CTLR=y unconditional, how much could we simplify
> mm/?
There will always be a remaining part that is only of interest to
people with memory cgroups, but that doesn't mean we can't shrink this
part to an adequate size.
> We are adding bits of overhead to the CONFIG_CGROUP_MEM_RES_CTLR=n case
> all over the place. This patchset actually decreases the size of allnoconfig
> mm/built-in.o by 1/700th.
Most of the memcg code should be completely optimized away with =n,
except for some on-stack data structures that have a struct mem_cgroup
pointer.
In the meantime, major distros started to =y per default and people
are complaining that memcg functions show up in the profiles of their
non-memcg workload. This one worries me more.
> A "struct mem_cgroup" sometimes gets called "mem", sometimes "memcg",
> sometimes "mem_cont". Any more candidates? Is there any logic to
> this?
I used memcg throughout except for two patches that I fixed up. I
don't think there is any reason to keep them different, so I'll send a
fix to rename the remaining ones to memcg.
> Anyway... it all looks pretty sensible to me, but the timing (at
> -rc8!) is terrible. Please keep this material maintained for -rc1, OK?
Thanks, and yeah, the timing is ambitious, I hoped that the deferred
release and merge window could make it possible.
I'll keep it uptodate.
--
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:[~2011-10-04 7:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 21:00 [patch 00/10] memcg naturalization -rc4 Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-29 21:00 ` [patch 01/10] mm: memcg: consolidate hierarchy iteration primitives Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-29 21:00 ` [patch 02/10] mm: vmscan: distinguish global reclaim from global LRU scanning Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-29 21:00 ` [patch 03/10] mm: vmscan: distinguish between memcg triggering reclaim and memcg being scanned Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-29 21:00 ` [patch 04/10] mm: memcg: per-priority per-zone hierarchy scan generations Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-30 9:25 ` Michal Hocko
2011-09-30 9:25 ` Michal Hocko
2011-09-29 21:00 ` [patch 05/10] mm: move memcg hierarchy reclaim to generic reclaim code Johannes Weiner
2011-09-29 21:00 ` Johannes Weiner
2011-09-29 21:01 ` [patch 06/10] mm: memcg: remove optimization of keeping the root_mem_cgroup LRU lists empty Johannes Weiner
2011-09-29 21:01 ` Johannes Weiner
2011-09-29 21:01 ` [patch 07/10] mm: vmscan: convert global reclaim to per-memcg LRU lists Johannes Weiner
2011-09-29 21:01 ` Johannes Weiner
2011-09-29 21:01 ` [patch 08/10] mm: collect LRU list heads into struct lruvec Johannes Weiner
2011-09-29 21:01 ` Johannes Weiner
2011-09-29 21:01 ` [patch 09/10] mm: make per-memcg LRU lists exclusive Johannes Weiner
2011-09-29 21:01 ` Johannes Weiner
2011-09-29 21:01 ` [patch 10/10] mm: memcg: remove unused node/section info from pc->flags Johannes Weiner
2011-09-29 21:01 ` Johannes Weiner
2011-09-30 8:05 ` [patch 00/10] memcg naturalization -rc4 KAMEZAWA Hiroyuki
2011-09-30 8:05 ` KAMEZAWA Hiroyuki
2011-09-30 9:32 ` Johannes Weiner
2011-09-30 9:32 ` Johannes Weiner
2011-10-03 10:04 ` KAMEZAWA Hiroyuki
2011-10-03 10:04 ` KAMEZAWA Hiroyuki
2011-09-30 9:31 ` Michal Hocko
2011-09-30 9:31 ` Michal Hocko
2011-10-03 23:11 ` Andrew Morton
2011-10-03 23:11 ` Andrew Morton
2011-10-04 7:47 ` Johannes Weiner [this message]
2011-10-04 7:47 ` Johannes Weiner
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=20111004074723.GA13681@redhat.com \
--to=jweiner@redhat.com \
--cc=akpm00@gmail.com \
--cc=bsingharora@gmail.com \
--cc=gthelen@google.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=minchan.kim@gmail.com \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=riel@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.