On 28 Jan 2021, at 2:03, Matthew Wilcox (Oracle) wrote:
> We have trouble keeping track of whether we've already called
> compound_head() to ensure we're not operating on a tail page. Further,
> it's never clear whether we intend a struct page to refer to PAGE_SIZE
> bytes or page_size(compound_head(page)).
>
> Introduce a new type 'struct folio' that always refers to an entire
> (possibly compound) page, and points to the head page (or base page).
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
> ---
> include/linux/mm.h | 26 ++++++++++++++++++++++++++
> include/linux/mm_types.h | 17 +++++++++++++++++
> 2 files changed, 43 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 2d6e715ab8ea..f20504017adf 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -924,6 +924,11 @@ static inline unsigned int compound_order(struct page *page)
> return page[1].compound_order;
> }
>
> +static inline unsigned int folio_order(struct folio *folio)
> +{
> + return compound_order(&folio->page);
> +}
> +
> static inline bool hpage_pincount_available(struct page *page)
> {
> /*
> @@ -975,6 +980,26 @@ static inline unsigned int page_shift(struct page *page)
>
> void free_compound_page(struct page *page);
>
> +static inline unsigned long folio_nr_pages(struct folio *folio)
> +{
> + return compound_nr(&folio->page);
> +}
> +
> +static inline struct folio *next_folio(struct folio *folio)
> +{
> + return folio + folio_nr_pages(folio);
Are you planning to make hugetlb use folio too?
If yes, this might not work if we have CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_VMEMMAP
with a hugetlb folio > MAX_ORDER, because struct page might not be virtually contiguous.
See the experiment I did in [1].
[1] https://lore.kernel.org/linux-mm/16F7C58B-4D79-41C5-9B64-A1A1628F4AF2@xxxxxxxxxx/
—
Best Regards,
Yan Zi
Attachment:
signature.asc
Description: OpenPGP digital signature
