linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Oscar Salvador <OSalvador@suse.com>,
	Yuanxi Liu <y.liu@naruida.com>,
	David Hildenbrand <david@redhat.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: page_alloc: Assume huge tail pages are valid when allocating contiguous pages
Date: Fri, 14 Apr 2023 10:55:04 +0200	[thread overview]
Message-ID: <ZDkU6PuuDsUb82lr@dhcp22.suse.cz> (raw)
In-Reply-To: <20230414082222.idgw745cgcduzy37@techsingularity.net>

On Fri 14-04-23 09:22:22, Mel Gorman wrote:
[...]
> +
> +		/*
> +		 * Do not migrate huge pages that span the size of the region
> +		 * being allocated contiguous. e.g. Do not migrate a 1G page
> +		 * for a 1G allocation request. CMA is an exception as the
> +		 * region may be reserved for hardware that requires physical
> +		 * memory without a MMU or scatter/gather capability.
> +		 *
> +		 * Note that the compound check is race-prone versus
> +		 * free/split/collapse but it should be safe and result in
> +		 * a premature skip or a useless migration attempt.
> +		 */
> +		if (PageHuge(page) && compound_nr(page) >= nr_pages &&
> +		    !is_migrate_cma_page(page)) {
> +			return false;

Is the CMA check working as expected? The function sounds quite generic
and I agree that it would make sense if it was generic but it is used
only for GB pages in fact and unless I am missing something it would
allow to migrate CMA pages and potentially allocate over that region
without any possibility to migrate GB page out so the CMA region would
be essentially unusable for CMA users. GB pages already have their CMA
allocator path before we get to alloc_contig_pages. Or do I miss
something?
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2023-04-14  8:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14  8:22 Mel Gorman
2023-04-14  8:55 ` Michal Hocko [this message]
2023-04-14  9:52   ` Mel Gorman
2023-04-14 10:19     ` Michal Hocko
2023-04-14 10:31       ` David Hildenbrand
2023-04-14 12:22 ` Matthew Wilcox
2023-04-14 13:29   ` Mel Gorman
2023-04-14 19:06 ` Mike Kravetz
2023-04-14 20:07   ` Mike Kravetz

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=ZDkU6PuuDsUb82lr@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=OSalvador@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=vbabka@suse.cz \
    --cc=y.liu@naruida.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox