Re: Where to put page->memdesc initially

[David Hildenbrand <david@redhat.com>]

On 02.09.25 23:06, Matthew Wilcox wrote:
> 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.

I was wondering whether there could be a single patch where we do this 
change (separate allocations), and just prepare the code in previous 
patches for that accordingly, such that the resulting patch is still 
reasonable small.

I feel like this way of splitting patches might cause unnecessary 
headaches :)

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

IIRC, we must always make sure to never call folio_test_anon() on 
something that is a slab already.

But if in doubt, we could use bit[2] in ->mapping, which should still be 
unussed IIRC.

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

Makes sense, but maybe we can avoid all that by just structuring the 
patches differently :)

-- 
Cheers

David / dhildenb