Subject: Re: What are pmap->pm_{v,p}ptpt and PROCESS_PAGE_TBLS_BASE
To: None <Richard.Earnshaw@buzzard.freeserve.co.uk,>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm
Date: 06/05/2001 00:10:38
On Monday 04 June 2001 11:28 pm, Richard Earnshaw wrote:
> > Could someone bear with another question from me, and elucidate the
> > reasoning behind and layout of the PROCESS_PAGE_TBLS_BASE area (or has
> > its origin been lost in the midst of time, marked "here be dragons")?
>
> OK, let me see what I can remember (I'm doing this at least partly for my
> own benefit).

[snip richard beating me to the send button with a explanation that looked 
clearer than mine]

> As to some of the history behind this, some is definitely lost in the mists
> of time.  The original arm pmap code was derived from the old i386 pmap
> code; and after he had ported it, Mark commented that it probably wasn't
> the best place to start from.  Since then, of course, the i386 pmap has
> been completely rewritten, and the current version would have formed a much
> better starting place.

Which is something I've been investigating doing.  And it's rather complex 
area, I'm getting there, but haven't had much time.  Should have time to look 
at it again tommorrow night.  I might actually check a few things in, after 
running them past the list, eg using a pool for pmaps, having a list of pmaps 
(needed to implement growkernel), that kind of thing.  oh and some of the 
uses of pmap_map_ptes instead of pmap_pte.  There are a few other 
optimisations to do, and features to add, eg pmap_growkernel could be useful 
is we extend the KVM space.

In reality the arm32 pmap actually looks more like the 4.4BSD pmap interface, 
which is due to it's origins in the i386 pmap.  In fact I remember a spate 
when every 2 mins or whenever sync ran the whole machine froze for 2 seconds 
while the pmap thrashed the caches (that was back in 1.2 or 1.3 days...)

Chris