]> git.karo-electronics.de Git - karo-tx-linux.git/commit
x86, mm: probe memory block size for generic x86 64bit
authorYinghai Lu <yinghai@kernel.org>
Thu, 24 Apr 2014 22:55:27 +0000 (08:55 +1000)
committerStephen Rothwell <sfr@canb.auug.org.au>
Thu, 24 Apr 2014 22:55:27 +0000 (08:55 +1000)
commit970395c41ed9043cdbf5f45b546148c6c23838a3
tree9eab8f17640eefc07ecde35775f57d6aeffde603
parent3ac3d36bbac3ea59360963fa80907a537079c824
x86, mm: probe memory block size for generic x86 64bit

On system with 2TiB ram, current x86_64 have 128M as section size, and one
memory_block only include one section.  So will have 16400 entries under
/sys/devices/system/memory/.

Current code try to use block id to find block pointer in /sys
for any section, and reuse that block pointer. that finding will take some time
even after

| commit 7c243c7168dcc1bc2081fc0494923cd7cc808fb6
| Author: Russ Anderson <rja@sgi.com>
| Date:   Mon Apr 29 15:07:59 2013 -0700
|    mm: speedup in __early_pfn_to_nid

that will skip the search in that case during booting up.

So solution could be increase block size just like SGI UV system did.
(harded code to 2g).

This patch is trying to probe the block size to make it match mmio remap
size.  for example, Intel Nehalem later system will have memory range [0,
TOML), [4g, TOMH].  If the memory hole is 2g and total is 128g, TOM will
be 2g, and TOM2 will be 130g.

We could use 2g as block size instead of default 128M.  That will reduce
number of entries in /sys/devices/system/memory/

On system 6TiB system will reduce boot time by 35 seconds.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
arch/x86/mm/init_64.c