Date: Tue, 08 Jan 2013 11:35:26 -0600 From: Alan Cox <alc@rice.edu> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@FreeBSD.org, Ian Lepore <freebsd@damnhippie.dyndns.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Oleksandr Tymoshenko <gonzo@FreeBSD.org> Subject: Re: svn commit: r245147 - head/sys/arm/include Message-ID: <50EC58DE.2050402@rice.edu> In-Reply-To: <20130108172135.GA2561@kib.kiev.ua> References: <201301080240.r082eKVq080302@svn.freebsd.org> <20130108030022.GC82219@kib.kiev.ua> <50EBA947.1030902@freebsd.org> <20130108155641.GG82219@kib.kiev.ua> <1357664471.1088.131.camel@revolution.hippie.lan> <20130108172135.GA2561@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50EC58DE.2050402>