On 25.09.22 01:04, Matthew Wilcox wrote:
On Mon, Sep 19, 2022 at 09:57:08PM +0900, Hyeonggon Yoo wrote:
For now, only SLAB uses _mapcount field as a number of active objects in
a slab, and other slab allocators do not use it. As 16 bits are enough
for that, use remaining 16 bits of _mapcount as page_type even when
SLAB is used. And then move PG_slab flag to page_type!
Note that page_type is always placed in upper 16 bits of _mapcount to
avoid confusing normal _mapcount as page_type. As underflow (actually
I mean, yeah, overflow) is not a concern anymore, use more lower bits
except bit zero.
Add more folio helpers for PAGE_TYPE_OPS() not to break existing
slab implementations.
Remove PG_slab check from PAGE_FLAGS_CHECK_AT_FREE. buddy will still
check if _mapcount is properly set at free.
Exclude PG_slab from hwpoison and show_page_flags() for now.
Note that with this patch, page_mapped() and folio_mapped() always return
false for slab page.
This is an interesting approach. It raises some questions.
First, you say that folio_mapped() returns false for slab pages. That's
only true for order-0 slab pages. For larger pages,
if (!folio_test_large(folio))
return atomic_read(&folio->_mapcount) >= 0;
if (atomic_read(folio_mapcount_ptr(folio)) >= 0)
return true;
so that's going to depend what folio_mapcount_ptr() aliases with.
Second, this patch changes the behaviour of PageSlab() when applied to
tail pages. Which raises the further question of what PageBuddy(),
PageTable(), PageGuard() and PageIsolated() should do for multi-page
folios, if that is even possible.
IIRC, these flags never apply on real compound pages so far. For
example, PageBuddy() is only set on the first page of a (budy-aligned)
free chunk of memory, and all "remaining" (tail) pages have a refcount
of zero and don't have the flag set.
There are page tables on some systems (e.g., s390x) that span multiple
pages (pmd_alloc_one()). I think the behavior is similar -- no compound
page, and only the first page has the flag set.
--
Thanks,
David / dhildenb
