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.
