LWN: Comments on "Fleshing out memory descriptors"

Fleshing out memory descriptors

willy — Mon, 27 May 2024 18:56:20 +0000

Oh, interesting idea. That's a path to getting us to a 16 byte struct page sooner. I like it. There's various other work to be done to remove the use of page->flags (mostly things like looking up the zone/node/etc), but that needs to happen anyway.

Fleshing out memory descriptors

pbonzini — Mon, 27 May 2024 18:29:25 +0000

It is clearer in the wiki, yes:

struct page {
    union {
        unsigned long memdesc;
        struct buddy buddy;
    };
};

Would it make sense to tackle the "private" field _last_ (not first) by sticking it in the second word of struct page, that is:

struct page {
    unsigned long memdesc_or_next;
    unsigned long private_or_prev;
};

Fleshing out memory descriptors

willy — Mon, 27 May 2024 17:57:50 +0000

Indeed, I did not mention it in the talk.

The mechanism is to mark the slab cache for allocating a memdesc as TYPESAFE_BY_RCU. Then something like GUP-fast can be implemented by rcu_read_lock(); READ_ONCE(&page->memdesc); check the memdesc type; subtract off the type and cast the result to a folio; try_get() the refcount and then rcu_read_unlock(). Now you have a refcount so the folio can't be freed under you. You then need to check that the page table still refers to the same page and the page is part of the same memdesc. Now you're safe.

For the page cache, it's simpler because the page cache contains folio pointers, so it's the same check we do now.

I haven't spent much time thinking about the physical memory walkers (eg compaction and memory-failure). They seem like simpler cases than GUP-fast since there's no PTE to examine; we're going straight from a PFN to a memdesc. Although they're more complex because they have to handle memdescs which are not folios.

You're probably right that it needs an rcu_store or something to make sure the memdesc initialisation is ordered before the store to page->memdesc. I'll listen to the experts once we get to that point in the conversion!

Thanks for bringing it up.

Fleshing out memory descriptors

pbonzini — Mon, 27 May 2024 17:30:39 +0000

Matthew, looking https://kernelnewbies.org/MatthewWilcox/FolioAlloc what is going to be the policy for lockless or RCU-protected access to descriptors? I imagine that the descriptors are fine because no one should even try to read the descriptor for that pfn until after folio_alloc returns; but I think that there would be some kind of atomic_store_release or smp_wmb() at the end, and a matching rcu_dereference() or READ_ONCE() when reading the memdesc field.

Fleshing out memory descriptors

willy — Mon, 27 May 2024 16:09:43 +0000

Hm, now I re-read the article, it's a little confusing and I see how someone could come away with the impression that there is.

There is not. I do not propose ever allocating a struct buddy.

That's clear in the wiki pages, I hope. And if it is, then I'll remedy that.

Fleshing out memory descriptors

willy — Mon, 27 May 2024 16:07:44 +0000

There is no separately allocated struct buddy. Did you not read the article? Or the wiki pages that are linked?

Fleshing out memory descriptors

koverstreet — Mon, 27 May 2024 15:07:28 +0000

to get rid of the separately allocated struct buddy

we talked about this before, I think the ultimate conclusion was that the linked lists in the buddy allocator really aren't that bad so probably not worth the hassle - just throwing it out there in case it gets revisited or someone ambitious comes along

Fleshing out memory descriptors

willy — Mon, 27 May 2024 14:23:02 +0000

... and the page might be HIGHMEM.

I already got it down to a u64, not sure why you're trying to complicate it further?

Fleshing out memory descriptors

koverstreet — Mon, 27 May 2024 14:05:14 +0000

struct buddy could be reduced to a single ulong by switching the linked lists for indices into radix trees.

The tricky part is that freeing a page then inserts onto a radix tree, which might allocate - recursion.

You can satisfy the allocation from the page you're freeing, but that might have to be split, so it gets tricky.