[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5315E986.7070608@parallels.com>
Date: Tue, 4 Mar 2014 18:56:06 +0400
From: Vladimir Davydov <vdavydov@...allels.com>
To: <hannes@...xchg.org>, <mhocko@...e.cz>
CC: <akpm@...ux-foundation.org>, <glommer@...il.com>,
<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<devel@...nvz.org>
Subject: Re: [PATCH -mm 00/12] kmemcg reparenting
Hi Johannes, Michal
Could you please take a look at this set when you have time?
Thank you.
On 02/26/2014 07:05 PM, Vladimir Davydov wrote:
> Hi,
>
> During my recent attempt to push kmemcg shrinkers, I was pointed out
> that current kmemcg implementation has a serious design flaw - it lacks
> reparenting. Currently each memcg cache holds a css ref to its memcg and
> does not let it go until the cache is emptied. Although this approach is
> simple, it leads to memcgs hanging around for quite a long time after
> the death, which is ugly. Building something on top of that is
> unacceptable. So this patch set targets on implementing reparenting for
> kmemcg charges.
>
> [ for more details see the discussion thread:
> https://lkml.org/lkml/2014/2/11/623 ]
>
> It is based on top of 3.14.0-rc4-mmotm and organized as follows:
> - Patches 1-3 fix some nasty races in kmemcg implementation. I could
> not let them live any longer, because they touch the code I'm going
> to modify.
> - Patches 4-6 prepare memcg_cache_params for reparenting.
> - Patch 7 rework slab charging making it easier to track and therefore
> reparent kmem charges, and patches 8-10 kill the old charging code.
> - Patch 11 introduces kmemcg reparenting.
> - Patch 12 is for slub. It fixes sysfs naming clashes that can arise
> due to reparented caches.
>
> Please note that this patch set does not resolve all kmemcg-related
> issues - there are still plenty of them (e.g. "dangling" caches), but it
> is already big enough so I guess I'll address them later when this one
> is committed (if it will be committed at all, of course).
>
> Many thanks to Johannes Weiner, who proposed the idea and kindly
> outlined basic design principles.
>
> Thanks,
>
> Vladimir Davydov (12):
> memcg: flush cache creation works before memcg cache destruction
> memcg: fix race in memcg cache destruction path
> memcg: fix root vs memcg cache destruction race
> memcg: move slab caches list/mutex init to memcg creation
> memcg: add pointer from memcg_cache_params to cache
> memcg: keep all children of each root cache on a list
> memcg: rework slab charging
> memcg: do not charge kmalloc_large allocations
> fork: do not charge thread_info to kmemcg
> memcg: kill GFP_KMEMCG and stuff
> memcg: reparent slab on css offline
> slub: make sure all memcg caches have unique names on sysfs
>
> include/linux/gfp.h | 5 -
> include/linux/memcontrol.h | 133 ++-------
> include/linux/slab.h | 15 +-
> include/linux/thread_info.h | 2 -
> include/trace/events/gfpflags.h | 1 -
> kernel/fork.c | 4 +-
> mm/memcontrol.c | 587 +++++++++++++++++----------------------
> mm/page_alloc.c | 35 ---
> mm/slab.c | 47 ++--
> mm/slab.h | 17 +-
> mm/slab_common.c | 100 +++++--
> mm/slub.c | 88 ++++--
> 12 files changed, 470 insertions(+), 564 deletions(-)
>
--
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