On Wed, Mar 31, 2021 at 02:14:00PM -0400, Johannes Weiner wrote:
> Anyway, we digressed quite far here. My argument was simply that it's
> conceivable we'll switch to a default allocation block and page size
> that is larger than the smallest paging size supported by the CPU and
> the kernel. (Various architectures might support multiple page sizes,
> but once you pick one, that's the smallest quantity the kernel pages.)
We've had several attempts in the past to make 'struct page' refer to
a different number of bytes than the-size-of-a-single-pte, and they've
all failed in one way or another. I don't think changing PAGE_SIZE to
any other size is reasonable.
Maybe we have a larger allocation unit in the future, maybe we do
something else, but that should have its own name, not 'struct page'.
I think the shortest path to getting what you want is having a superpage
allocator that the current page allocator can allocate from. When a
superpage is allocated from the superpage allocator, we allocate an
array of struct pages for it.
> I don't think folio as an abstraction is cooked enough to replace such
> a major part of the kernel with it. so I'm against merging it now.
>
> I would really like to see a better definition of what it actually
> represents, instead of a fluid combination of implementation details
> and conveniences.
Here's the current kernel-doc for it:
/**
* struct folio - Represents a contiguous set of bytes.
* @flags: Identical to the page flags.
* @lru: Least Recently Used list; tracks how recently this folio was used.
* @mapping: The file this page belongs to, or refers to the anon_vma for
* anonymous pages.
* @index: Offset within the file, in units of pages. For anonymous pages,
* this is the index from the beginning of the mmap.
* @private: Filesystem per-folio data (see attach_folio_private()).
* Used for swp_entry_t if FolioSwapCache().
* @_mapcount: How many times this folio is mapped to userspace. Use
* folio_mapcount() to access it.
* @_refcount: Number of references to this folio. Use folio_ref_count()
* to read it.
* @memcg_data: Memory Control Group data.
*
* A folio is a physically, virtually and logically contiguous set
* of bytes. It is a power-of-two in size, and it is aligned to that
* same power-of-two. It is at least as large as %PAGE_SIZE. If it is
* in the page cache, it is at a file offset which is a multiple of that
* power-of-two.
*/
struct folio {
/* private: don't document the anon union */
union {
struct {
/* public: */
unsigned long flags;
struct list_head lru;
struct address_space *mapping;
pgoff_t index;
unsigned long private;
atomic_t _mapcount;
atomic_t _refcount;
#ifdef CONFIG_MEMCG
unsigned long memcg_data;
#endif
/* private: the union with struct page is transitional */
};
struct page page;
};
};
