Re: Where to put page->memdesc initially

[David Hildenbrand <david@redhat.com>]

On 02.09.25 21:03, Matthew Wilcox wrote:
> With the recent patches to slab, I'm just about ready to allocate struct
> slab separately from struct page.  This will not be an immediate win,
> of course.  Indeed, it will likely be a slowdown (overhead of a second
> allocation per slab).  So there's no urgency to do this until we're
> ready to shrink struct page, when we can at least point to that win
> as justification.
> 
> Still, we should understand how we're going to get to Page2025 [1] one
> step at a time.  I had been thinking about coopting compound_head to point
> to struct slab.  But looking at the places which call folio_test_slab()
> [an oxymoron in the New York Interpretation], it becomes apparent that
> we need to keep compound_head() and page_folio() working for all pages
> for a while.
> 
> As a reminder, compound_head() will _eventually_ return NULL for
> slabs & folios.  It will only be defined to work for page allocations.
> Likewise page_folio() will return NULL for any pages not part of a folio
> and page_slab() will return NULL for any pages not part of a slab.
> 
> My best offer right now is to use page->lru.prev.  At least one of the
> bottom two bits will be set to indicate that it's a memdesc (we're only
> going to use thirteen of the memdesc types initially).
> 

Just so I understand it correctly:

Would you want to move the page type already from the mapcount into the
memdesc? That sounds challenging, because for any typed folios we would
not be allowed to reuse a field we want to use for the memdesc. IIRC<
hugetlb pretty much uses all of it.

The easy way out for now would be making this page type specific: Only
selected typed pages will store the memdesc (here: slab pointer) e.g.,
in the old page->mapping place.

So PageSlab() still checks the existing page type, put page_slab() would
simply lookup the pointer in the old page->mapping place.


> There are a few overlapping uses of these bits in struct page, so if we do
> nothing we may get confused.  We can deal with mlock_count and order (for
> pcp_llist).  But the biggest problem is the first tail page of a folio.
> Depending on word size and endianness, there are four different atomic_t
> fields that overlap with page->lru.prev.  That can't be solved by using
> a different field in struct page; the first tail page is jam-packed.
> 
> So, page_slab() will first load page->memdesc (the same bits as
> page->lru.prev), check the bottom four bits match the slab memdesc, and
> also check page->page_type matches PGTY_slab.  I don't like this a lot,
> because it's two loads rather than one atomic load, but it should only
> be present for one commit.

As a first step, I would really not use the bottom four bits. Why
perform two type checks initially?

-- 
Cheers

David / dhildenb