From: Michal Hocko <email@example.com>
To: Oscar Salvador <firstname.lastname@example.org>
Cc: Anshuman Khandual <email@example.com>,
Subject: Re: [PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page()
Date: Thu, 21 Mar 2019 11:03:16 +0100 [thread overview]
Message-ID: <20190321100316.GN8696@dhcp22.suse.cz> (raw)
On Thu 21-03-19 10:42:40, Oscar Salvador wrote:
> On Thu, Mar 21, 2019 at 09:43:15AM +0530, Anshuman Khandual wrote:
> > pfn_valid_within() calls pfn_valid() when CONFIG_HOLES_IN_ZONE making it
> > redundant for both definitions (w/wo CONFIG_MEMORY_HOTPLUG) of the helper
> > pfn_to_online_page() which either calls pfn_valid() or pfn_valid_within().
> > pfn_valid_within() being 1 when !CONFIG_HOLES_IN_ZONE is irrelevant either
> > way. This does not change functionality.
> > Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
> > Signed-off-by: Anshuman Khandual <firstname.lastname@example.org>
> About the "Fixes:" tag issue, I agree with Michal that the code is not
> really broken, but perhaps "suboptimal" depending on how much can affect
> performance on those systems where pfn_valid_within() is more complicated than
> simple returning true.
> I see that on arm64, that calls memblock_is_map_memory()->memblock_search(),
> to trigger a search for the region containing the address, so I guess it
> is an expensive operation.
> Depending on how much time we can shave, it might be worth to have the tag
> Fixes, but the removal of the code is fine anyway, so:
Yeah, seeing a noticesable slowdown (actual numbers) would warrant a
backport to 5.0.
next prev parent reply other threads:[~2019-03-21 10:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 4:13 [PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page() Anshuman Khandual
2019-03-21 5:01 ` Zi Yan
2019-03-21 5:33 ` Anshuman Khandual
2019-03-21 8:07 ` Michal Hocko
2019-03-21 8:13 ` Anshuman Khandual
2019-03-21 9:42 ` Oscar Salvador
2019-03-21 10:03 ` Michal Hocko [this message]
2019-03-22 9:23 ` Michal Hocko
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.