Mail Archives: djgpp/2003/10/24/20:30:29
Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:
:> Why are 4MB pages or swapping the 4KB page tables necessary? Can't you
:> just allocate some memory above 1.1MB and put the page tables that
:> won't fit in conventional memory there?
: Due to the size of a 1GB-4GB address space, you will get sub-optimal
: performance using 4KB pages since the address lookups can't all be cached.
Yes. So what? Do we want standard compliance that works everywhere? Or
a hack that works only if special circumstances apply?
: So using 4MB pages improves performance vs. 4KB pages. Performance
: testing shows improvements on a 500MB random memory array using 4MB
: pages.
Yes. But as you said yourself that won't be VCPI compatible.
I don't myself see why that won't be VCPI compatible if the first 4MiB
is mapped with ordinary 4KiB pages. You should be permitted to do
sever abominations above 4MiB.
Perhaps VDS comes into the way? (Pure speculation.)
: Putting all the page tables into extended address space would require a
: mode switch redesign - the initial page fault handler would need to run
: in PM to look at the tables, switch to real mode to extract a buffer
: from disk, then copy data from the RM buffer.
: This is uglier than it seems, since all the table initialization code
: also needs to visit protected mode (so it's multi-pass aware, first
: visit doesn't have page tables all set up and in right place).
: For these reasons, I decided implementing 4MB pages was a better way to
: spend time than supporting 4MB worth of 4KB page tables.
Yes. But you also decided to be not VCPI compatible.
: PMODE avoids the issue completely by not turning on paging at all
: unless it must to deal with VCPI.
And what will happen if PMODE finds itself in a VCPI environment? (I
don't expect you to answer this as you're not the author. It's a
question to the PMODE author. Feel free to answer it anyway if you
feel you're knowledgable about it.)
Right,
MartinS
- Raw text -