All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Matthew Wilcox <willy@infradead.org>
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 14:29:40 +0100	[thread overview]
Message-ID: <20230414132940.chjmsuiurnygajxs@techsingularity.net> (raw)
In-Reply-To: <ZDlFbkwfmePEewXM@casper.infradead.org>

On Fri, Apr 14, 2023 at 01:22:06PM +0100, Matthew Wilcox wrote:
> 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. 

Given the calling context is a linear scan, the head page will be scanned
first so the value for compound_nr() called on a tail page shouldn't occur.

> 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?
> 

For now I only want hugetlbfs pages as the fix is for a regression when
allocating 1G hugetlbfs pages and previous behaviour avoided existing
hugetlbfs pages. THP pages can be split+migrated of course but the cost
of the 1G allocation attempt may be excessive relative to any benefit.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2023-04-14 13:29 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
2023-04-14 13:29   ` Mel Gorman [this message]
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=20230414132940.chjmsuiurnygajxs@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --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=mhocko@suse.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --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 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.