From: Dave Hansen <dave.hansen@intel.com>
To: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
Michal Hocko <mhocko@kernel.org>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Sistare <steven.sistare@oracle.com>
Subject: Re: [PATCH v2] x86/mm: use max memory block size on bare metal
Date: Thu, 11 Jun 2020 10:05:38 -0700 [thread overview]
Message-ID: <adcd3359-a90b-ab62-60e1-102277533e11@intel.com> (raw)
In-Reply-To: <20200611165910.6dwd3c7z5brimjbm@ca-dmjordan1.us.oracle.com>
On 6/11/20 9:59 AM, Daniel Jordan wrote:
> On Thu, Jun 11, 2020 at 07:16:02AM -0700, Dave Hansen wrote:
>> On 6/9/20 3:54 PM, Daniel Jordan wrote:
>>> + /*
>>> + * Use max block size to minimize overhead on bare metal, where
>>> + * alignment for memory hotplug isn't a concern.
>>> + */
>>> + if (hypervisor_is_type(X86_HYPER_NATIVE)) {
>>> + bz = MAX_BLOCK_SIZE;
>>> + goto done;
>>> + }
>> What ends up being the worst case scenario? Booting a really small
>> bare-metal x86 system, say with 64MB or 128MB of RAM? What's the
>> overhead there?
> Might not be following you, so bear with me, but we only get to this check on a
> system with a physical address end of at least MEM_SIZE_FOR_LARGE_BLOCK (64G),
> and this would still (ever so slightly...) reduce overhead of memory block init
> at boot in that case.
Ahh, I see now. That is just above the hunk you added, but just wasn't
in the diff context or mentioned in the changelog.
One other nit for this. We *do* have actual hardware hotplug, and I'm
pretty sure the alignment guarantees for hardware hotplug are pretty
weak. For instance, the alignment guarantees for persistent memory are
still only 64MB even on modern platforms.
Let's say we're on bare metal and we see an SRAT table that has some
areas that show that hotplug might happen there. Is this patch still
ideal there?
next prev parent reply other threads:[~2020-06-11 17:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 22:54 Daniel Jordan
2020-06-09 23:03 ` Daniel Jordan
2020-06-10 7:20 ` David Hildenbrand
2020-06-10 7:30 ` David Hildenbrand
2020-06-10 17:16 ` Daniel Jordan
2020-06-11 14:16 ` Dave Hansen
2020-06-11 16:59 ` Daniel Jordan
2020-06-11 17:05 ` Dave Hansen [this message]
2020-06-12 3:29 ` Daniel Jordan
2020-06-19 12:07 ` Michal Hocko
2020-06-22 19:17 ` Daniel Jordan
2020-06-26 12:47 ` Michal Hocko
2020-07-08 18:46 ` Daniel Jordan
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=adcd3359-a90b-ab62-60e1-102277533e11@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.m.jordan@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=peterz@infradead.org \
--cc=steven.sistare@oracle.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