From: Matthew Wilcox <willy@infradead.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
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 13:22:06 +0100 [thread overview]
Message-ID: <ZDlFbkwfmePEewXM@casper.infradead.org> (raw)
In-Reply-To: <20230414082222.idgw745cgcduzy37@techsingularity.net>
On Fri, Apr 14, 2023 at 09:22:22AM +0100, 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 &&
This confuses me. PageHuge() can be called on tail pages, but if
compound_nr() is called on a tail page, it returns 1. So I'm not
sure why this works. Also, do you really want PageHuge (ie only
hugetlbfs pages), or do you really just want to check PageCompound(),
which would also be true for THP?
next prev parent reply other threads:[~2023-04-14 12:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 8:22 [PATCH] mm: page_alloc: Assume huge tail pages are valid when allocating contiguous pages Mel Gorman
2023-04-14 8:55 ` Michal Hocko
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 [this message]
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=ZDlFbkwfmePEewXM@casper.infradead.org \
--to=willy@infradead.org \
--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=mhocko@suse.com \
--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