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
