Subject: Re: kernel mappings of shared-library pages
To: Chuck Silvers <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 10/15/2001 21:14:46
> 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
1) Different ARM processors all have different amounts of cache, that
would make the code highly processor specific. Well we could cope with
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
So how would this make the pmap code any easier?