> > >i think the check could be done within pmd_bad() [pgd_bad()] conditions,
> > >which branches already exist for all relevant cases. Thus the code path
> > >would not differ for normal mappings.
>
> Umm, you're making a rather serious logic mistake here:
> - we have debugging code that is reasonably expensive
> - we could hide real code in the same expense
> - so the real code is "free"
>
> Don't you see the fallacy? We can remove the debugging code (and quite
> frankly, I thought I had done so already until I went back and checked -
> it hasn't found anything at all in the last two years or so except for bad
> memory).
independent of the 4M issue, i think this 'debugging code' is a good
barrier to keep the side effects of hardware errors from spreading. I've
seen it working numerous times. We have such functional redundancy in many
important places, and i think this helps general stability much more than
it looks at first sight. [the page table cache made things slightly worse
already, it 'preserves' one-bit errors across forks and execs] Although
there are no guarantees at all wrt hardware errors, i think it makes sense
to think about what rare 1-bit errors can do to the kernel, in a
statistical sense, to improve robustness.
> > Another solution could be to implement a very arch specific i386 syscall
> > that give us a 4 mbyte view (not allocation) of some piece of phisical
> > memory. Maybe is a bad idea ;-).
>
> Note that we'll probably need this in the future for other reasons, namely
> the new 36-bit physical extensions. The only way to access the high memory
> is through a 4MB mapping (unless you want to go to the three-level page
> tables that slow everything else down), and it's really only useful for
> database caches.
>
> In short, it's not as special as you think. I've been considering it for
> Oracle - that's how you use 8GB of memory on a Xeon box.
hm, this covers PCI area mappings too. But it's still present in the user
page tables, unless we pre-partition virtual memory, which i dont think is
a smart idea.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/