svn commit: r245147 - head/sys/arm/include

[Alan Cox]

On 01/08/2013 11:21, Konstantin Belousov wrote:
> On Tue, Jan 08, 2013 at 10:01:11AM -0700, Ian Lepore wrote:
>> I'm just learning the armv6/v7 stuff myself right now, but I can answer
>> your question for our current armv4/v5 implementation...
>>
>> When there is more than one mapping of a page in v4/v5 and any one of
>> those mappings is writable, then the pmap.c code changes all existing
>> mappings to be uncacheable to maintain coherency.  If the writable
>> mapping is removed and all that remains are read/exec mappings, the
>> existing mappings are made cacheable again.  Yes, that's just as
>> inefficient and expensive as it sounds.  :)
> Interesting, so the arm/pmap.c in fact maintain pv entries even for the
> unmanaged pages and kernel mappings ?

There is a special case mechanism for such mappings.  Look for the kva
field in the md page struct.

> ... But this approach, requiring pv
> entries for the kernel mappings, makes kernel pv entries non-reclamable
> on the low memory condition. In fact, I cannot find any traces of the pv
> reclaim in the arm/pmap.c.

Yes, arm will simply panic.  Moreover, the individual pv entries are
more than twice the size of i386 or mips.