Re: 4MB pages and framebuffer access, x11perf results, 2.1.125

Linus Torvalds (torvalds@transmeta.com)
Thu, 29 Oct 1998 09:11:02 -0800 (PST)


On Thu, 29 Oct 1998, Andrea Arcangeli wrote:
> Ingo Molnar 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).

> 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.

Linus

-
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/