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.
Third, can we do this without that awkward __u16 thing? Perhaps
-#define PG_buddy 0x00000080
-#define PG_offline 0x00000100
-#define PG_table 0x00000200
-#define PG_guard 0x00000400
+#define PG_buddy 0x00010000
+#define PG_offline 0x00020000
+#define PG_table 0x00040000
+#define PG_guard 0x00080000
+#define PG_slab 0x00100000
... and then use wrappers in slab.c to access the bottom 16 bits?
