On Wed, Feb 22, 2023 at 02:08:28AM +0800, Gao Xiang wrote:
> On 2023/1/27 00:40, Matthew Wilcox wrote:
> > I'd like to do another session on how the struct page dismemberment
> > is going and what remains to be done. Given how widely struct page is
> > used, I think there will be interest from more than just MM, so I'd
> > suggest a plenary session.
>
> I'm interested in this topic too, also I'd like to get some idea of the
> future of the page dismemberment timeline so that I can have time to keep
> the pace with it since some embedded use cases like Android are
> memory-sensitive all the time.
As you all know, I'm absolutely amazing at project management & planning
and can tell you to the day when a feature will be ready ;-)
My goal for 2023 is to get to a point where we (a) have struct page
reduced to:
struct page {
unsigned long flags;
struct list_head lru;
struct address_space *mapping;
pgoff_t index;
unsigned long private;
atomic_t _mapcount;
atomic_t _refcount;
unsigned long memcg_data;
#ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
int _last_cpupid;
#endif
};
and (b) can build an allnoconfig kernel with:
struct page {
unsigned long flags;
unsigned long padding[5];
atomic_t _mapcount;
atomic_t _refcount;
unsigned long padding2;
#ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
int _last_cpupid;
#endif
};
> Minor, it seems some apis still use ->lru field to chain bulk pages,
> perhaps it needs some changes as well:
> https://lore.kernel.org/r/20221222124412.rpnl2vojnx7izoow@xxxxxxxxxxxxxxxxxxx
> https://lore.kernel.org/r/20230214190221.1156876-2-shy828301@xxxxxxxxx
Yang Shi covered the actual (non-)use of the list version of the bulk
allocator already, but perhaps more importantly, each page allocated
by the bulk allocator is actually a separately tracked allocation.
So the obvious translation of the bulk allocator from pages to folios
is that it allocates N order-0 folios.
That may not be the best approach for all the users of the bulk allocator,
so we may end up doing something different. At any rate, use of page->lru
isn't the problem here (yes, it's something that would need to change,
but it's not a big conceptual problem).
