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