| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
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