yea, several of the VAC platforms don't.

but now I'm thinking that it may be better to make some new APIs for
cache stuff rather than loading it into the existing pmap operations,
since there may be times when you know you don't need to flush the cache.
let me think about this some more...

-Chuck


On Tue, Jul 10, 2001 at 02:17:08PM +0100, Richard Earnshaw wrote:
> > well, that does bring up an interesting point:  for this optimization to work,
> > pmap_clear_modify() will have to flush any VAC after clearing the state which
> > indicates the page is modified.  (the "after" part is important in a
> > multiprocessor environment to handle races with other cpus dirtying
> > the page again.)
> 
> Well pmap_clear_modify doesn't clean the VAC either before or after 
> clearing the modify bit.
> 
> R.
> 
> 
> > On Tue, Jul 10, 2001 at 10:01:17AM +0100, Richard Earnshaw wrote:
> > > 
> > > chuq@chuq.com said:
> > > >  (2) when we're reading the page from memory to write it to backing
> > > > store.
> > > >      this use also involves careful ordering of operations in
> > > >      pmap_clear_modify(), so that any writes to the page via other
> > > >      mappings which could end up in different cache lines will also
> > > >      result in the page being marked modified again, so that we'll
> > > >      be forced to write the page to backing store again at some point
> > > >      in the future. 
> > > 
> > > Hmm, I'm not sure if this is relevant, but the arm32 pmap_protect() 
> > > implementation does not flush the cache when a page is marked read-only.  
> > > I discovered this to my cost when trying to optimize pmap_copy_page to 
> > > minimize cache flushes.
> > > 
> > > R.
>