linux-kernel - Re: [PATCH v7 17/19] mm: memcg/slab: use a single set of kmem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200718230322.GB124789@carbon.DHCP.thefacebook.com>
Date:   Sat, 18 Jul 2020 16:03:22 -0700
From:   Roman Gushchin <guro@...com>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Shakeel Butt <shakeelb@...gle.com>, <linux-mm@...ck.org>,
        Vlastimil Babka <vbabka@...e.cz>, <kernel-team@...com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 17/19] mm: memcg/slab: use a single set of kmem_caches
 for all allocations

On Sat, Jul 18, 2020 at 10:24:49AM -0700, Guenter Roeck wrote:
> On Tue, Jun 23, 2020 at 10:40:35AM -0700, Roman Gushchin wrote:
> > Instead of having two sets of kmem_caches: one for system-wide and
> > non-accounted allocations and the second one shared by all accounted
> > allocations, we can use just one.
> > 
> > The idea is simple: space for obj_cgroup metadata can be allocated on
> > demand and filled only for accounted allocations.
> > 
> > It allows to remove a bunch of code which is required to handle kmem_cache
> > clones for accounted allocations.  There is no more need to create them,
> > accumulate statistics, propagate attributes, etc.  It's a quite
> > significant simplification.
> > 
> > Also, because the total number of slab_caches is reduced almost twice (not
> > all kmem_caches have a memcg clone), some additional memory savings are
> > expected.  On my devvm it additionally saves about 3.5% of slab memory.
> > 
> > Suggested-by: Johannes Weiner <hannes@...xchg.org>
> > Signed-off-by: Roman Gushchin <guro@...com>
> > Reviewed-by: Vlastimil Babka <vbabka@...e.cz>
> > Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
> 
> This patch results in:
> 
> {standard input}: Assembler messages:
> {standard input}:140: Warning: macro instruction expanded into multiple instructions
> mm/slub.c: In function 'slab_alloc.constprop':
> mm/slub.c:2897:30: error: inlining failed in call to always_inline 'slab_alloc.constprop': recursive inlining
>  static __always_inline void *slab_alloc(struct kmem_cache *s,
> 
> and many similar messages when trying to build mips:64r6el_defconfig
> or mips:defconfig. Bisect log attached.

Hello, Guenter!

Thank you for reporting the problem!
Actually, I've already fixed it, and Andrew pulled the fix yesterday.
So in few days the fix should appear in the next tree.

Sorry for the inconvenience and please let me know if the problem will persist
after a couple of days.

Roman