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.
