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

[Ian Lepore]

On Tue, 2013-01-08 at 19:21 +0200, 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 ? 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.

Well, I didn't say it did all this *correctly*.  (I guess I implied
that.)

The first added kernel mapping doesn't generate a separate pv entry, it
gets noted in the main pv struct, but then if yet another kernel entry
is added it gets added as a normal pv entry.  I've always assumed that
was intended as a performance boost for short-lived temporary kernel
mappings.

I don't know about the reclaiming stuff.  All my work with armv4 has
been on small embedded systems compiled with option NO_SWAPPING, so in
my experience one is just careful to not use too much memory, because
when you do, things start to die.

-- Ian