From owner-svn-src-head@FreeBSD.ORG Tue Jan 8 17:42:27 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7E20141C; Tue, 8 Jan 2013 17:42:27 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2A61FF76; Tue, 8 Jan 2013 17:42:27 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r08HgQpD028419; Tue, 8 Jan 2013 10:42:26 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r08HgNDU095239; Tue, 8 Jan 2013 10:42:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: svn commit: r245147 - head/sys/arm/include From: Ian Lepore To: Konstantin Belousov 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> Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Jan 2013 10:42:23 -0700 Message-ID: <1357666943.1088.137.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, Oleksandr Tymoshenko , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:42:27 -0000 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