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?
