All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm: remove pfn_valid_within() and CONFIG_HOLES_IN_ZONE
Date: Tue, 13 Jul 2021 13:22:07 +0300	[thread overview]
Message-ID: <YO1pT1bjMfldbQKg@kernel.org> (raw)
In-Reply-To: <7300dfe1-0c6a-ae2e-2c48-c885248ec263@redhat.com>

On Tue, Jul 13, 2021 at 11:51:46AM +0200, David Hildenbrand wrote:
> On 13.07.21 10:00, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > After recent changes in freeing of the unused parts of the memory map and
> > rework of pfn_valid() in arm and arm64 there are no architectures that can
> > have holes in the memory map within a pageblock and so nothing can enable
> > CONFIG_HOLES_IN_ZONE which guards non trivial implementation of
> > pfn_valid_within().
> > 
> > With that, pfn_valid_within() is always hardwired to 1 and can be
> > completely removed.
> > 
> > Remove calls to pfn_valid_within() and CONFIG_HOLES_IN_ZONE.
> > 
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> 
> There is currently the discussion to increase MAX_ORDER, for example, to
> cover 1GiB instead of 4MiB on x86-64. This would mean that we could
> suddenly, again, have holes insides MAX_ORDER - 1 pages.
> 
> So I assume if we ever go down that path, we'll need something like this
> again.

It depends whether pageblock_order will be also increased. PFN walkers rely
on continuity of pageblocks rather than MAX_ORDER chunks, so if
pageblock_order won't change, there won't be need to check for pfn_valid()
inside a pageblock.
 
> For now, this looks like the right thing to do
> 
> Acked-by: David Hildenbrand <david@redhat.com>

Thanks!

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2021-07-13 10:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  8:00 [PATCH 0/2] mm: remove pfn_valid_within() and CONFIG_HOLES_IN_ZONE Mike Rapoport
2021-07-13  8:00 ` [PATCH 1/2] " Mike Rapoport
2021-07-13  9:51   ` David Hildenbrand
2021-07-13 10:22     ` Mike Rapoport [this message]
2021-07-13 10:24       ` David Hildenbrand
2021-07-13 20:02         ` Zi Yan
2021-07-13  8:00 ` [PATCH 2/2] mm: memory_hotplug: cleanup after removal of pfn_valid_within() Mike Rapoport
2021-07-13  9:54   ` David Hildenbrand

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=YO1pT1bjMfldbQKg@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rafael@kernel.org \
    --cc=rppt@linux.ibm.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.