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

[Kent Overstreet <kent.overstreet@linux.dev>]

On Fri, Mar 08, 2024 at 06:26:11PM +0000, 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?  ;-)
> 
> It could, just about, be done.  Although not on Hexagon with its crazy
> 256kB page.  Right now, I reserve 0xf000007f to catch over/underflow,
> although this is perhaps excessive and I could get away with just
> 0x8000007f.  That leaves 24 bits.  We've currently got 4 in use, and I
> want to add two more (Slab and HugeTLB), so there's 18 bits remaining.
> 
> 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?

Ok, this is the first I'd seen of these PageType shenanigans :)

That definitely takes priority over shaving cycles here; but could we
clean that up and expand it?

Does it really need to be a bitmask? And really, enums should be enums
(that we can give a proper type name to) not #defines and raw ints.

If we did that, and killed PG_slab and made it part of the PageType
enum, that frees up a few bits.