On Mon, Jan 13, 2003 at 12:14:17PM +0000, Steve Woodford wrote:

 > So, I'm soliciting opinions on what's wrong with the existing pmap, and
 > suggestions on either how to bend existing code into shape, or how to do
 > things differently/better with new code.

Off the top of my head:

	* Way way way too much I$ frobbing happens in the current pmap.
	  It seems as if in the current code, everytime the D$ is futzed
	  with, so is the I$.  This is a silly big-hammer approach, and
	  certainly could be optimized.

	  For user pmaps, I suggest a strategy like the one used by the
	  Alpha pmap.  That is, do not do ANY user I$ frobbing until the
	  actual return to userspace by a proc/lwp using that pmap.  A
	  side-effect is that you'd have to nail the entire I$ if the pmap
	  is marked as needing I$-sync, but that may still be faster.

	  (Note that with this strategy, you would still do any write-back
	  neccessary while in the kernel, just would skip the I$ flush part
	  of the step until userret().)

	  If it ends up not working out, at the very least the pmap needs
	  to be made more intelligent about when it actually needs to futz
	  with the I$.  Tracking exec permission in the PV entry would be
	  a good start.  (No exec'able mappings will ever be kenter'd, so
	  you don't need to worry about it there.)

	* Right now, the "PTPT" (the page table that maps the pmap's
	  page tables) is mapped at multiple addresses.  This means
	  that it cannot be accessed in a cached fashion.  Really, all
	  page table management in the current pmap is gross, and it
	  really needs to be revisited.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>