From owner-svn-src-all@FreeBSD.ORG Tue Jan 8 17:40:57 2013 Return-Path: Delivered-To: svn-src-all@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 CAC2516E; Tue, 8 Jan 2013 17:40:57 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id A6280F53; Tue, 8 Jan 2013 17:40:57 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 5133F4601B7; Tue, 8 Jan 2013 11:35:27 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 4F6CA4601FA; Tue, 8 Jan 2013 11:35:27 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id rlPTR0Tj4pGB; Tue, 8 Jan 2013 11:35:27 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id B38A74601F2; Tue, 8 Jan 2013 11:35:26 -0600 (CST) Message-ID: <50EC58DE.2050402@rice.edu> Date: Tue, 08 Jan 2013 11:35:26 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r245147 - head/sys/arm/include 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> In-Reply-To: <20130108172135.GA2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, Ian Lepore , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Oleksandr Tymoshenko X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:40:57 -0000 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.