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@xxxxxxxxxxx>
> > Signed-off-by: Roman Gushchin <guro@xxxxxx>
> > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
> > Reviewed-by: Shakeel Butt <shakeelb@xxxxxxxxxx>
>
> 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
