tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mmap implementation advice needed.
(Should this be moved to somewhere VAX-specific, maybe?)
> The problem was/is (if I understood it right), that someone can mmap
> more than 1G, and that will never be possible to map on the VAX.
Well...close.
> The P0 space is only 1G, and the same is true for the P1 space. But
> P0 and P1 is disjunct, so don't try to think of them as contiguous
> space.
But they are contiguous: the top of P0 space abuts the bottom of P1
space.
The problem is, P0 grows up and P1 grows down, so taking advantage of
that contiguity means both spaces must be fully existent (in the sense
that the P0 and P1 length registers must indicate that all possible
pages exist). That means two 8M chunks of system virtual space to
contain all those PTEs. And _that_ means two 64K chunks out of the
(physically contiguous) block holding system PTEs - which means either
moving the system page tables live or allocating over 128K for system
PTEs at boot, each of which has its own problems. Well over 128K, if
you want to quickly switch among multiple such processes.
And, even then, you'd still be limited to 2G. In principle, this could
be raised to a little under 3G; nothing says system pages can't be
accessible to user mode. But it would greatly complicate - and slow
down - task switching, because there is no hardware assist for
switching the system-space portion. ("A little under" 3G because you'd
need 16M of system virtual space for P0/P1 page tables, plus at least
one page for trap handler entry points. Unless you want to get really
fancy, you'll also need space for kernel text/data/bss.)
If you just want more than 1G mapped, but mapped in small chunks, then
you don't need to use the point where P0 abuts P1. But you will still
need that (approximately) 1/16384th as much physical space as your
total user space, for system PTEs to map user PTEs.
> So, anything trying to grab more than 1G will never be possible.
Probably. Theoretically possible, but unlikely to ever be implemented.
> But it would appear that the MI part don't give any hooks to stop a
> process from going just that.
Isn't the VAX pmap code in a position to reject attempts to allocate
virtual space it doesn't support?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index