Re: [PATCH] mm/slub: Make __ksize() faster

["Christoph Lameter (Ampere)" <cl@gentwo.org>]

On Fri, 8 Mar 2024, Matthew Wilcox wrote:

> On Fri, Mar 08, 2024 at 09:12:06AM -0800, Christoph Lameter (Ampere) wrote:
>>
>>> On Fri, Mar 08, 2024 at 11:27:32AM -0500, Kent Overstreet wrote:
>>>> On Fri, Mar 08, 2024 at 02:58:48PM +0000, Matthew Wilcox wrote:
>>>>> There are potentiually better uses for those bits.  We could turn
>>>>> folio_test_slab() into a PageType test, freeing up a page flag.
>>>>
>>>> They overlap _mapcount, did you figure out how to use that for a
>>>> PageType enum?
>>>
>>> In 2018 ... 6e292b9be7f4358985ce33ae1f59ab30a8c09e08
>>>
>>
>> This seems to be 32 bit field. We could segment that into two unsigned
>> shorts. In fact any operation on a slab larger than 2xPAGE_SIZE is directly
>> turned into a page allocator call bypassing slub. So you only need 0 ... 2 *
>> PAGE_SIZE for the range of the int.
>
> Are there any CPUs with PAGE_SIZE > 65535?  ;-)

Yes. PPC has something like that I believe. Otherwise 64K is popular on 
ARM64 f.e.

> So is it really worth burning all the remaining bits on implementing
> ksize with one fewer pointer dereference, given that struct kmem_cache
> is read-mostly and should live in the CPU cache quite well?

No idea. Yes struct kmem cache must be cache hot anyways for 
operations on a cache. So make sure to move the object size to the 
beginning of kmem_cache so that it shares a cacheline (this should already 
be the case??). Then there should really be no win from relocating the 
size. But we have 32 precious bits to play around with. That is an 
important discussion on what to do with them.