Jason Thorpe said:
> On Mon, 1 Feb 1999 22:02:41 -0500 (EST) 
>  "John S. Dyson" <dyson@iquest.net> wrote:
> 
>  > Mapping /dev/(k)mem on machines without aliasing problems isn't a real
>  > problem, because the user mappings will have the pv entries.  A modification
>  > required to pmap_kremove (even in the FreeBSD codebase), would be to chase
>  > down the pv entries.  That overhead would be needed only if there were any pv
>  > entries, which would be an exceptional circumstance.
> 
> No, the issue here is:
> 
> Say you have a system (like the MIPS) which can have alias problems
> between user and kernel mode (i.e. the cache has no notion of user vs.
> supervisor mappings).
> 
> You pmap_kenter() a page in the kernel.
> 
> Now, you happen to mmap that same page with an aliasing virtual address.
> 
> The pmap_kenter() routine didn't add a pv entry.  Now you're screwed.
> 
> Granted, this _is_ an exceptional case, but it is a defficiency worth noting.
> 
I agree.

There are some architectures where some optimizations are not appropriate,
and one goal (at least one of my goals) is to try to support the optimizations
are appropriate for different architectures.  Most of my work had been on the
X86, and so I tend to have an X86 bias.  However, there are likely other
optimizations appropriate for other architectures also.  (e.g. fast tlb fills
in very very tight assembly for those machines that don't have microcoded
page table mgmt.)  As you already know :-), the alpha does that in various
versions through the PALcode mechanism.  One terrible thing that I noticed
when working on a certain other U**X clone (okay, a real U**X), was that
there was no specially efficient handling of tlb fills :-(, and that was
a real performance problem for a specific machine that I worked on.  The
performance dropped through the floor when the tlb was thrashed.  IMO,
both the higher level algorithm needed to be improved, but the faults would
have been alot cheaper with careful low level design.

Historically, virtual caches have been a bit of a problem for OS developers.  It
isn't so much that the are difficult to handle, but it they are more often
a *different* problem to handle a virtual cache than to handle a physical
cache or no cache.

In the case where pmap_kenter/pmap_kremove needs to do pv tracking, then one
can create the semantics by using a flag in a pv entry (or perhaps use the
VA hack.)  On machines that don't have aliasing issues to deal with, it is
kind-of nice to be able to utilize that fact.  In fact, on some architectures,
it might not be bad to make pmap_kenter/pmap_kremove macros that call a
common pmap_enter_internal type routine -- maybe, maybe not?

I think that one challenge for a very portable OS, is to work the issue of
all of these subtile features from an efficiency or performance standpoint.
Below is an anecdote of where an additional feature on a chip can trick one
into using the feature, when it is best to ignore it most of the time (or
perform the function in a way to avoid the need to use the feature.)

Anecdote:
	One optimization that I have found not to be as useful as I had originally
thought was the PG_M bit on the X86.  It is really only maximally useful on
shared writeable mappings.  At one time, I had been biased towards using it,
(in fact, went out of my way to use it) but eventually found that it was best
not to use it except in limited circumstances.  At first, I thought that it
was bad that some processors didn't have a modified bit, but with efficient
(tightly coded) TLB management, it isn't needed...  Even on an X86 -- again
except on shared writeable mappings.

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.