[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8932b0f9-0d25-7298-c12c-b4ae455ef110@suse.cz>
Date: Tue, 26 May 2020 16:55:05 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Roman Gushchin <guro@...com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
kernel-team@...com, linux-kernel@...r.kernel.org,
Jesper Dangaard Brouer <brouer@...hat.com>,
Mel Gorman <mgorman@...hsingularity.net>
Subject: Re: [PATCH v3 17/19] mm: memcg/slab: use a single set of kmem_caches
for all allocations
On 4/22/20 10:47 PM, 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>
However, as this series will affect slab fastpaths, and perhaps especially this
patch will affect even non-kmemcg allocations being freed, I'm CCing Jesper and
Mel for awareness as they AFAIK did work on network stack memory management
performance, and perhaps some benchmarks are in order...
Powered by blists - more mailing lists