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.)

-Chuck


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.