Chuck Cranor writes:
> On Fri, Jan 29, 1999 at 01:09:54PM -0800, Jason Thorpe wrote:
> > 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?
> 
> it might be possible, i didn't define it one way or the other, so
> i'll have to look into it.
> 
> 
> regarding the usage of pmap_kenter and its interaction with
> mod/ref bits and VAC aliases: you are only supposed to use
> pmap_kenter() for mapping where those issues don't matter
> (e.g. private kernel mappings).   John Dyson's message clearly
> explained it the way i was thinking about it so i won't bother 
> to repeat it again.
> 
> 
> on a related note, i don't consider the PMAP_NEW related stuff
> set in stone, so the issue of revising the interface is still
> on the table [or on a back burner at this point given some of
> my other concerns].


while we're talking about changing interfaces, there's another
tweak to the behaviour of pmap_enter() that I've found useful:
a flag to indicate that the mapping will only be accessed via DMA
and thus there's no reason to flush the cache when unmapping it.
this adjustment got my unified cache code the last 5% of the way
to matching the performance of the -current on my "cp -r" test case.
(at least I think this optimization is valid, it seemed to work).
this would only be useful on a few architectures, but it does help.

I think changing pmap_enter() to handle multiple pages and
turning the "wired" arg into "flags" would be good things.

-Chuck