On 2023/2/22 03:58, Matthew Wilcox wrote:
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 ;-)
yeah, but this core stuff actually impacts various subsystems, it would
be better to get some in advance otherwise I'm not sure if I could have
extra slots to handle these.
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
};
Okay, with the plan above, how to make it work with memdesc in the long
term?
Also in the future at least I'd like to know if it's possible / how to
get folio itself from page and how to know if some folio is actually
truncated or connected to some (or more) inodes.
Anyway, all of the above are interesting to me, and that could avoid
some extra useless folio adoption in the opposite direction. Also I
could have more rough thoughts how to get page cache sharing work.
I could imagine many of them may be still in the preliminary form
for now, but some detailed plans would be much helpful.
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).
Yes, I just would like to confirm how to use such apis in the long term.
Currently it's no rush for me but I tend to avoid using them in a vague
direction.
Thanks,
Gao Xiang
