Subject: Re: CVS commit: syssrc/sys/arch/arm/arm32
To: Chuck Silvers <chuq@chuq.com>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 07/10/2001 14:17:08
> 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.