• Jesse Barnes's avatar
    x86, 32-bit: trim memory not covered by wb mtrrs · 99fc8d42
    Jesse Barnes authored
    On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all
    available RAM, meaning the last few megs (or even gigs) of memory will be
    marked uncached.  Since Linux tends to allocate from high memory addresses
    first, this causes the machine to be unusably slow as soon as the kernel
    starts really using memory (i.e.  right around init time).
    
    This patch works around the problem by scanning the MTRRs at boot and
    figuring out whether the current end_pfn value (setup by early e820 code)
    goes beyond the highest WB MTRR range, and if so, trimming it to match.  A
    fairly obnoxious KERN_WARNING is printed too, letting the user know that
    not all of their memory is available due to a likely BIOS bug.
    
    Something similar could be done on i386 if needed, but the boot ordering
    would be slightly different, since the MTRR code on i386 depends on the
    boot_cpu_data structure being setup.
    
    This patch fixes a bug in the last patch that caused the code to run on
    non-Intel machines (AMD machines apparently don't need it and it's untested
    on other non-Intel machines, so best keep it off).
    
    Further enhancements and fixes from:
    
      Yinghai Lu <Yinghai.Lu@Sun.COM>
      Andi Kleen <ak@suse.de>
    Signed-off-by: default avatarJesse Barnes <jesse.barnes@intel.com>
    Tested-by: default avatarJustin Piszcz <jpiszcz@lucidpixels.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Yinghai Lu <yhlu.kernel@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    99fc8d42
if.c 10.1 KB