On Fri, 29 Jan 1999, Jason Thorpe wrote:

> [ Moving this to tech-kern, BCC'ing the list it was previously on.  --thorpej ]
> 
> On Fri, 29 Jan 1999 09:38:47 -0500 
>  Chuck Cranor <chuck@research.att.com> wrote:
> 
>  >    i looked at this on the i386 a while back but i haven't had
>  > time to figure out how to fix it.   the problem on the i386 is that
>  > pmap_kenter() adds kernel mappings without bumping up the kernel
>  > pmap's pm_stats.resident_count  [it can't bump it as-is because
>  > it doesn't have a lock on the kernel pmap's simplelock.]
> 
> Why doesn't it just acquire that lock, then?  Is it defined in the
> pmap_kenter() API that the kernel pmap will not be locked?
> 
> ...what if a given pmap implementation MUST lock the kernel pmap to
> enter a mapping?
> 
> This actually brings up another problem w/ pmap_kenter() that I've
> been meaning to bring up.
> 
> The big deal with pmap_kenter() is that it's faster than the normal
> pmap_enter() path, because it can make some assumptions... it also
> has the specified feature of not doing PV tracking, which is required
> for uvm_loan() to work (prevents certain mappings from being e.g.
> pmap_page_protect()'d, etc.)
> 
> Unfortunately, the lack of PV-tracking has two problems:
> 
> 	(1) For hardware mod/ref, if you must traverse the PV list
> 	    to get this information, you may lose mod/ref info!
> 
> 	    For software mod/ref emulation (e.g. Alpha), you have the

And UltraSPARC

> 	    problem of not being able to set those mappings to Fault on
> 	    Read/Fault on Write, and thus you also lose mod/ref info!
> 
> 	(2) On VAC systems (like the HP 320 and HP 350 and on the MIPS R4000),

And UltraSPARC

> 	    it's necessary to cache-inhibit all mappings if a multiple-mapping
> 	    causes a VAC alias (not likely with PMAP_PREFER(), but can
> 	    still happen).  Without these PV entries, we can't cache
> 	    inhibit all mappings, and thus we have a cache coherency problem!
> 
> What I'm thinking about doing on the Alpha and hp300 pmaps is instead
> use a bit to say "entered w/ kenter" in the PV entry, so that the
> desired operations (e.g. pmap_page_protect()) are skipped on those
> mappings, but the info can be tracked for the other needs.

I find the pmap_kenter() interface to be an abomination.  In addition to
the above two issues (both of which I find bothersome since I need to
handle them) there is the issue of keeping mappings entered through both
pmap_enter() and pmap_kenter() and the associated code paths consistent.  

The one nice thing about pmap_kenter() is that it will allow multiple
pages to be mapped at the same time.  This is a feature I would like to be
able to make use of to use large PTEs where appropriate.  However, this
feature would be most useful for user mappings where a program or shared
library's text or data segments could be mapped in with a single PTE.

What I would prefer would be to dump pmap_kenter() and instead change
pmap_enter() (and other functions that currently only operate on a single
page) to take a range of pages and possibly a parameter to tell pmap that
these pages will never be multiply mapped.  

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me