kernel_optimize_test/arch/x86
Hugh Dickins a06de63000 x86: fix /proc/meminfo DirectMap
Do we actually want these DirectMap lines in the x86 /proc/meminfo?
I can see they're interesting to CPA developers and TLB optimizers,
but they don't fit its usual "where has all my memory gone?" usage.
If they are to stay, here are some fixes.

1. On x86_32 without PAE, they're not 2M but 4M pages: no need to
   mess with the internal enum, but show the right name to users.

2. Many machines can never show anything but 0 for DirectMap1G,
   so suppress that line unless direct_gbpages are really enabled.

3. The unit in /proc/meminfo is kB not number of pages: HugePages
   messed that up, but they're an example to regret not to follow.

4. Once we use kB, it's easy to see that 1GB has gone missing (which
   explains why CONFIG_CPA_DEBUG=y soon wraps DirectMap2M negative):
   because head_64.S's level2_ident_pgt entries were not counted.
   My fix is not ideal, but works for more and for less than 1G,
   and avoids interfering with early bootup pagetable contortions.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-15 15:27:55 +02:00
..
boot x86: cleanup for setup code crashes during IST probe 2008-08-14 00:13:52 +02:00
configs
crypto
ia32
kernel x86: invalidate caches before going into suspend 2008-08-15 14:04:30 +02:00
kvm
lguest
lib x86: wrong register was used in align macro 2008-07-30 10:10:39 -07:00
mach-default
mach-es7000
mach-generic
mach-rdc321x
mach-voyager
math-emu
mm x86: fix /proc/meminfo DirectMap 2008-08-15 15:27:55 +02:00
oprofile
pci x86: silence mmconfig printk 2008-08-15 13:52:39 +02:00
power
vdso
video
xen
Kconfig arch/x86/Kconfig: clean up, experimental adjustement 2008-08-15 14:06:54 +02:00
Kconfig.cpu
Kconfig.debug
Makefile
Makefile_32.cpu