On Mon, 1 Feb 1999, John S. Dyson wrote:

> Jason Thorpe said:
> > 
> > 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.
> > 


Two issues with pmap_kenter:

> On FreeBSD, the pmap_kenter can be emulated by pmap_enter, depending
> on platform.  The purpose of pmap_kenter is to avoid dealing with all
> of the complexity of pmap_enter, when it simply isn't needed.  Most
> kernel mappings (except where there are aliasing problems, or when files
> are mmaped) don't require tracking of the modify and referenced bits.
> Pmap_kenter short-circuits the overhead associated with the pmap_kenter
> (pmap_kenter means "pmap kernel enter".)  Other data structures provide
> the needed tracking for resources.

There is no real separation between the interface and the implementation;
the interface implies the implementation.  

There is no reason for a separate interface other than the optimization
implemented by that interface, which assumes the existance of pv
structures to optimize away. You now have two sets of functions that
need to implement similar if not identical functionality to maintain in
parallel.  While I don't like the idea of all-singing all-dancing
functions that do 15 different unrelated things depending on their
arguments, some of the pmap_kenter optimizations are valid for pmap_enter.
When entering multiple pages at the same time pmap_enter could also
benefit from only a single MMU/cache invalidate for the whole lot.  This
improvement itself is likely to be larger than the removal of the pv
handling code.  The additional expense of checking some parameter in
pmap_enter to decide whether the page needs to be tracked by a pv
structure is negligible.  

I'm not arguing that the optimizations are not warranted in many cases.
It's just that the interface presumes certain optimizations and precludes
other equally valid ones.  

[...]

> Some machines might need a pv instrumented pmap_kenter, and in that case, the
> overhead associated with it cannot be avoided.  A good example of valid use
> for the pmap_kenter might be kernel malloced areas, buffer cache (to avoid
> that totally gross and bogus pte move stuff), and other low level kernel
> purposes.  The original pte move stuff in the buffer cache code is an
> example of a pseudo-pmap_enter, but without the layering and formalism.
> 
> Even on machines with virtual caches can take advantage of pmap_kenter
> type constructs (for example, again, the bogus direct pte mgmt in the
> buffer cache code), but the advantage would be lessened.

I'm still curious about what happens when a process decides to open
/dev/mem or /dev/kmem and map in parts of the kernel that don't have
associated pv structures.  It would seem impossible to handle cache
coloring issues or handle the situation where the kernel unmapps one of
its internal pages.

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