On Tue, Jan 16, 2018 at 04:09:32AM +0100, Ingo Molnar wrote:
>
> * Tony Luck <tony.luck@xxxxxxxxx> wrote:
>
> > v1->v2 0-day reported a build warning on 32-bit. Don't do 32-bit (see comment
> > at end of commit message). This fixed the build error, but then discussion on
> > the list went quiet. Repost to wake things up.
>
> It seems dubious to me to introduce a difference in behavior on 32-bit:
>
> > +static void mce_unmap_kpfn(unsigned long pfn)
> > +{
> > +#ifdef CONFIG_X86_64
> > + unsigned long decoy_addr;
>
> > + if (set_memory_np(decoy_addr, 1))
> > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> > +#endif
>
> ... to fix a build warning?
>
> 32-bit kernels might be under-tested, but if it's supposed to work I don't think
> we should bifurcate the behavior and uglify the code here.
I glossed over the issue in the commit message with this text:
All of this only applies to 64-bit systems. 32-bit kernel doesn't map
all of memory into kernel space. It isn't worth adding the code to unmap
the piece that is mapped because nobody would run a 32-bit kernel on a
machine that has recoverable machine checks.
Here's some more detail on *why* I believe nobody will need this on 32-bit:
Recoverable machine checks are only supported on Xeon-E7 from IvyBridge to
Broadwell, and on the "Gold" and "Platinum" Skylake models.
These are all intended for use in 4 socket systems.
To keep the high number of cores on these busy, you need good memory
bandwidth. So any sane configuration will have a minimum of on DIMM per
memory channel, so we can interleave across as many channels as possible.
So that's either 24 or 32 DIMMs (depending on 6 or 8 channels per socket).
So on the oldest of those systems (IvyBridge) with teeny 4GB DIMMs, we have 128GB.
Which doesn't boot on 32-bit (all "low" memory is used for "struct page").
But maybe a crazy person didn't populate all channels? Or booted with "mem=32G".
They still (mostly) don't need this. Most of their memory isn't mapped 1:1
because they don't have the virtual space for it. So the majority of errors
would be in HIGMMEM ... and so not mapped.
So is this worth adding code for some hypothetical user running 32-bit who
is somehow worried about the 800MB or so that is mapped 1:1
-Tony
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
