[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e924c39b-7636-4c34-bfe9-603cf07c21d3@linux.dev>
Date: Fri, 23 Feb 2024 11:36:25 +0800
From: Chengming Zhou <chengming.zhou@...ux.dev>
To: "Christoph Lameter (Ampere)" <cl@...ux.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, David Rientjes <rientjes@...gle.com>,
Jianfeng Wang <jianfeng.w.wang@...cle.com>, penberg@...nel.org,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org, roman.gushchin@...ux.dev,
42.hyeyoo@...il.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Chengming Zhou <zhouchengming@...edance.com>
Subject: Re: [PATCH] slub: avoid scanning all partial slabs in get_slabinfo()
On 2024/2/23 11:02, Christoph Lameter (Ampere) wrote:
> On Thu, 22 Feb 2024, Chengming Zhou wrote:
>
>> Anyway, I put the code below for discussion...
>
> Can we guestimate the free objects based on the number of partial slabs. That number is available.
>
Yeah, the number of partial slabs is easy to know, but I can't think of a way to
estimate the free objects, since __slab_free() is just double cmpxchg in most cases.
> How accurate need the accounting be? We also have fuzzy accounting in the VM counters.
Maybe not need to be very accurate, some delay/fuzzy should be acceptable.
Another direction I think is that we don't distinguish slabs on cpu partial list or
slabs on node partial list anymore (different with current behavior).
Now we have three scopes:
1. SL_ALL: include all slabs
2. SL_PARTIAL: only include partial slabs on node
3. SL_CPU: only include partail slabs on cpu and the using cpu slab
If we change SL_PARTIAL to mean all partial slabs, it maybe simpler.
Thanks.
Powered by blists - more mailing lists