From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86/vmemmap: Handle unpopulated sub-pmd ranges
Date: Tue, 2 Feb 2021 09:51:09 +0100 [thread overview]
Message-ID: <20210202085100.GA8263@linux> (raw)
In-Reply-To: <dd9dfa98-21df-70c8-d43d-e9a83889464c@redhat.com>
On Tue, Feb 02, 2021 at 09:35:09AM +0100, David Hildenbrand wrote:
> Yeah, last time I raised it was in
>
> https://lkml.kernel.org/r/20200703013435.GA11340@L-31X9LVDL-1304.local
>
> but I never got to clean it up myself.
I see.
> > So, IIRC we have two cases during hotplug:
> > 1) the ones that want memory blocks
> > 2) the ones that do not want them (pmem stuff)
> >
> > For #1, we always enforce section alignment in add_memory_resource, and for
> > #2 we always make sure the range is at least sub-section aligned.
> >
> > And the important stuff is that boot memory is no longer to be hot-removed
> > (boot memory had some strange layout sometimes).
>
> The vmemmap of boot mem sections is always fully populated, even with
> strange memory layouts (e.g., see comment in pfn_valid()). In addition, we
> can only offline+remove whole sections, so that should be fine.
You are right.
>
> >
> > So, given the above, I think it should be safe to drop that check in
> > remote_pte_table.
> > But do we really need to force page alignment in vmemmap_populate/vmemmap_free?
> > vmemmap_populate should already receive a page-aligned chunk because
> > __populate_section_memmap made sure of that, and vmemmap_free() should be ok
> > as we already filtered out at hot-adding stage.
> >
> > Of course, this will hold as long as struct page size of multiple of 8.
> > Should that change we might get trouble, but I do not think that can ever
> > happened (tm).
> >
> > But anyway, I am fine with placing a couple of checks in vmemmap_{populate,free}
> > just to double check.
> >
> > What do you think?
>
> I'd just throw in 1 or 2 VM_BUG_ON() to self-document what we expect and
> that we thought about these conditions. It's then easy to identify the
> relevant commit where we explain the rationale.
Fine by me, also on a second thought it is good to have some sort of clue
when looking at the code.
I will add that cleanup before the actual "fix" of the sub-pmd stuff.
thanks!
--
Oscar Salvador
SUSE L3
prev parent reply other threads:[~2021-02-02 8:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 6:40 [PATCH v2] x86/vmemmap: Handle unpopulated sub-pmd ranges Oscar Salvador
2021-01-29 12:46 ` David Hildenbrand
2021-02-02 7:52 ` Oscar Salvador
2021-02-02 8:35 ` David Hildenbrand
2021-02-02 8:51 ` Oscar Salvador [this message]
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=20210202085100.GA8263@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.