All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <muchun.song@linux.dev>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Zi Yan <ziy@nvidia.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH mm-unstable v2 1/3] mm/contig_alloc: support __GFP_COMP
Date: Thu, 22 Aug 2024 11:23:04 -0600	[thread overview]
Message-ID: <Zsdz-NFl4oqZ37_h@google.com> (raw)
In-Reply-To: <20240814035451.773331-2-yuzhao@google.com>

On Tue, Aug 13, 2024 at 09:54:49PM -0600, Yu Zhao wrote:
> Support __GFP_COMP in alloc_contig_range(). When the flag is set, upon
> success the function returns a large folio prepared by
> prep_new_page(), rather than a range of order-0 pages prepared by
> split_free_pages() (which is renamed from split_map_pages()).
> 
> alloc_contig_range() can be used to allocate folios larger than
> MAX_PAGE_ORDER, e.g., gigantic hugeTLB folios. So on the free path,
> free_one_page() needs to handle that by split_large_buddy().
> 
> Signed-off-by: Yu Zhao <yuzhao@google.com>
> ---
>  include/linux/gfp.h |  23 +++++++++
>  mm/compaction.c     |  41 ++--------------
>  mm/page_alloc.c     | 111 +++++++++++++++++++++++++++++++-------------
>  3 files changed, 108 insertions(+), 67 deletions(-)
> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index f53f76e0b17e..59266df56aeb 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -446,4 +446,27 @@ extern struct page *alloc_contig_pages_noprof(unsigned long nr_pages, gfp_t gfp_
>  #endif
>  void free_contig_range(unsigned long pfn, unsigned long nr_pages);
>  
> +#ifdef CONFIG_CONTIG_ALLOC
> +static inline struct folio *folio_alloc_gigantic_noprof(int order, gfp_t gfp,
> +							int nid, nodemask_t *node)
> +{
> +	struct page *page;
> +
> +	if (WARN_ON(!order || !(gfp | __GFP_COMP)))

Andrew, could you patch up the line above? This is what it's supposed
to check:

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 59266df56aeb..03ba9563c6db 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -452,7 +452,7 @@ static inline struct folio *folio_alloc_gigantic_noprof(int order, gfp_t gfp,
 {
 	struct page *page;
 
-	if (WARN_ON(!order || !(gfp | __GFP_COMP)))
+	if (WARN_ON(!order || !(gfp & __GFP_COMP)))
 		return NULL;
 
 	page = alloc_contig_pages_noprof(1 << order, gfp, nid, node);


  parent reply	other threads:[~2024-08-22 17:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14  3:54 [PATCH mm-unstable v2 0/3] mm/hugetlb: alloc/free gigantic folios Yu Zhao
2024-08-14  3:54 ` [PATCH mm-unstable v2 1/3] mm/contig_alloc: support __GFP_COMP Yu Zhao
2024-08-22  8:21   ` Yu Liao
2024-08-22 17:25     ` Yu Zhao
2024-08-22 18:36     ` Andrew Morton
2024-08-22 17:23   ` Yu Zhao [this message]
2024-08-22 18:42     ` Matthew Wilcox
2024-09-02 17:02       ` Yu Zhao
2024-11-19 15:29   ` David Hildenbrand
2024-11-19 16:12     ` Zi Yan
2024-11-19 16:25       ` David Hildenbrand
2024-11-19 16:31       ` David Hildenbrand
2024-11-19 16:41         ` Zi Yan
2024-11-19 16:49           ` David Hildenbrand
2024-11-19 16:52             ` David Hildenbrand
2024-11-20 15:55               ` Zi Yan
2024-11-20 16:13                 ` David Hildenbrand
2024-11-20 16:46                   ` Zi Yan
2024-08-14  3:54 ` [PATCH mm-unstable v2 2/3] mm/cma: add cma_{alloc,free}_folio() Yu Zhao
2024-08-22 17:24   ` Yu Zhao
2024-09-02 17:04     ` Yu Zhao
2024-08-14  3:54 ` [PATCH mm-unstable v2 3/3] mm/hugetlb: use __GFP_COMP for gigantic folios Yu Zhao
2024-08-16 15:23   ` Zi Yan
2024-08-16 16:02     ` Yu Zhao
2024-08-16 16:30       ` Zi Yan
2024-08-30 17:55 ` [PATCH mm-unstable v2 0/3] mm/hugetlb: alloc/free " jane.chu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zsdz-NFl4oqZ37_h@google.com \
    --to=yuzhao@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.