Subject: Re: pmap_extract()?
To: Chris G. Demetriou <>
From: Eduardo E. Horvath <>
List: tech-kern
Date: 01/16/1997 08:30:24
I will admit that I had not studied the vm code closely enough to notice
that the vm code checked to make sure pages were wired before calling
pmap_extract().  I am still surprized the daemon book makes no mention of
pmap_extract() as part of the pmap interface.  Was that part of the
original 4.4BSD implementation, or did it come from somewhere else?

On Wed, 15 Jan 1997, Chris G. Demetriou wrote:

> I'm not a VM guru, but it looks like pmap_extract() isn't used
> unappropriately here.  "how are these cases a problem?"

The full quote is:

"I think it will cause problems when moving to a full 64-bit (or at
least the current 40-bit) VAs."  

My recollection is that kernel mappings must be stored in statically
allocated structures to prevent deadlocks.  Since a full 64-bit
forward-mapped page table tree would take about 5 levels (assuming 8K
pages and 64-bit pointers) resulting in a statically allocated translation
table somewhere in the order of 10**12 bytes.  43-bit VAs would be
significanlty smaller at 8GB.  

O.K., you can get around this problem by severely restricting the kernel
address space.  Or use some other scheme for storing the mappings.  I'm
just finding it a bit hard to come up with a reasonably fast lookup scheme
that does not involve either huge amounts of wasted memory, arbitrary
restrictions on address space, or dynamic allocation.

Eduardo Horvath
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier