Messages in this thread | | | Date | Thu, 29 Oct 1998 18:24:53 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: 4MB pages and framebuffer access, x11perf results, 2.1.125 |
| |
On Thu, 29 Oct 1998, Linus Torvalds wrote:
> > >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/
| |