Re: [PATCH 03/62] mm: Split slab into its own type

[David Hildenbrand <david@redhat.com>]

On 13.10.21 20:31, Matthew Wilcox wrote:
> On Wed, Oct 13, 2021 at 02:08:57PM -0400, Johannes Weiner wrote:
>> Btw, I think slab_nid() is an interesting thing when it comes to page
>> polymorphy. We want to know the nid for all sorts of memory types:
>> slab, file, anon, buddy etc. In the goal of distilling page down to
>> the fewest number of bytes, this is probably something that should
>> remain in the page rather than be replicated in all subtypes.
> 
> Oh, this is a really interesting point.
> 
> Node ID is typically 10 bits (I checked Debian & Oracle configs for
> various architectures).  That's far more than we can store in the bottom
> bits of a single word, and it's even a good chunk of a second word.
> 
> I was assuming that, for the page allocator's memory descriptor and for
> that of many allocators (such as slab), it would be stored *somewhere*
> in the memory descriptor.  It wouldn't necessarily have to be the same
> place for all memory descriptors, and maybe (if it's accessed rarely),
> we delegate finding it to the page allocator's knowledge.
> 
> But not all memory descriptors want/need/can know this.  For example,
> vmalloc() might well spread its memory across multiple nodes.  As long
> as we can restore the node assignment again once the pages are vfree(),
> there's no particular need for the vmalloc memory descriptor to know
> what node an individual page came from (and the concept of asking
> vmalloc what node a particular allocation came from is potentially
> nonsense, unless somebody used vmalloc_node() or one of the variants).
> 
> Not sure there's an obviously right answer here.  I was assuming that at
> first we'd enforce memdesc->flags being the first word of every memory
> descriptor and so we could keep passing page->flags around.  That could
> then change later, but it'd be a good first step?
> 

<offtopic>
It's really hard to make an educated guess here without having a full
design proposal of what we actually want to achieve and especially how
we're going to treat all the corner cases (as raised already in
different context).

I'm all for simplifying struct page and *eventually* being able to
shrink it, even if we end up only shrinking by a little. However, I'm
not sold on doing that by any means (e.g., I cannot agree to any
fundamental page allocator rewrite without an idea what it does to
performance but also complexity). We might always have a space vs.
performance cost and saving space by sacrificing performance isn't
necessarily always a good idea. But again, it's really hard to make an
educated guess.

Again, I'm all for cleanups and simplifications as long as they really
make things cleaner. So I'm going to comment on the current state and
how the cleanups make sense with the current state.
</offtopic>

Node/zone is a property of a base page and belongs into struct page OR
has to be very easily accessible without any kind of heavy locking. The
node/zone is determined once memory gets exposed to the system (e.g., to
the buddy during boot or during memory onlining) and is stable until
memory is offlined again (as of right now, one could imagine changing
zones at runtime).

For example, node/zone information is required for (almost) lockless PFN
walkers in memory offlining context, to figure out if all pages we're
dealing with belong to one node/zone, but also to properly shrink
zones+nodes to eventually be able to offline complete nodes. I recall
that there are other PFN walkers (page compaction) that need this
information easily accessible.

-- 
Thanks,

David / dhildenb