Re: Where to put page->memdesc initially

[Matthew Wilcox <willy@infradead.org>]

On Tue, Sep 02, 2025 at 10:09:49PM +0200, David Hildenbrand wrote:
> 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.

That would definitely be part of the same series.  But possibly not the
same patch.  I think the series has to include separate allocations for
slab, folio and whichever other memdescs won't fit into 32 bytes.

> 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.

I *think* that's roughly the same as what I'm proposing, except
that we already have a meaning for "the bottom two bits of
folio->mapping are set", so there's potential confusion for
folio_test_anon() & friends.
> 
> > 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?

I'm concerned by things like compaction that are executing
asynchronously and might see a page mid-transition.  Or something like
GUP or lockless pagecache lookup that might get a stale page pointer.
It's a lot easier to reason about if we can do a single load and treat
that as a source of truth (with the appropriate reloads to make sure
nothing changed after we got a refcount).  Doing two loads makes
my brain hurt a bit because it introduces more possibilities for
inconsistency.  I'll need to write it up pretty carefully (which
annoys me because we're going to need it for a single or very
few commits ...)