On Thu, 7 Jun 2007, Jesse Barnes wrote:
On Thursday, June 7, 2007 1:16 am Andi Kleen wrote:
On Wed, Jun 06, 2007 at 12:29:23PM -0700, Jesse Barnes wrote:
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).
In theory -- while not recommended -- a BIOS could also
use a default fallback MTRR for cached and use explicit MTRRs to
map the non existing ranges uncached. Would it make sense to handle
this case?
Probably. I could just check the default memory type and bail out if
it's cacheable.
Should also probably have some command line option
to disable the check in case something bad happens with it.
Sure.
Another thing that might be sense to investigate in relationship
to this patch is large page mappings with MTRRs. iirc P4 and also K8
splits pages internally with MTRR boundaries and might have some
other bad side effects. Should we use this as hints to use 4K pages
for the boundary areas?
Or I could trim to the nearest large page boundary... We'd lose a
little more memory but it would keep things simple.
Jesse
How much more memory are we going to lose? Is mem= a better option if its
going to keep decreasing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
