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 incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines
Justin, feel free to test again if you have time and add your
Andi, as for large pages, do you think this is ok as is, or should
I trim a larger granularity? If so, what granularity?
Signed-off-by: Jesse Barnes <jesse.barnes@xxxxxxxxx>