> most likely this is coming from UBC mappings, which are always writable.
> 
Oh dear!  Is there any way we could drop that writable attribute?

> all of the other VAC pmaps look at whether multiple mappings will actually
> use different cache lines rather than whether any of the mappings are
> writable.  you should make the arm pmap do this too.

Hmm, I'd noticed that, but I don't see that that would help at all (at 
least, not if my understanding of the way caches work is anything like 
accurate).

1) Different ARM processors all have different amounts of cache, that 
would make the code highly processor specific.  Well we could cope with 
that, but:
2) All ARM cache implementations that I am aware of are set-associative.  
As far as I can tell, the trick used on the hp300 (to take an example that 
I think you are referring to) will only work with a direct-mapped cache.  
For set-associative caches, both entries can be in the cache at the same 
time.


So how would this make the pmap code any easier?

R.