From owner-svn-src-all@FreeBSD.ORG Sun Dec 29 19:25:48 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 797695C2; Sun, 29 Dec 2013 19:25:48 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 369881249; Sun, 29 Dec 2013 19:25:47 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id rBTJDDGf024770; Sun, 29 Dec 2013 13:15:25 -0600 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp2.rice.edu with ESMTP id 1h2e2503n5-1; Sun, 29 Dec 2013 13:15:25 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id A95A340134; Sun, 29 Dec 2013 13:15:24 -0600 (CST) Message-ID: <52C074CA.4040208@rice.edu> Date: Sun, 29 Dec 2013 13:15:22 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r259908 - head/sys/vm References: <201312260546.rBQ5kAoJ009798@svn.freebsd.org> <52BF6699.1040006@freebsd.org> <52BF7195.2070606@rice.edu> <20131229090053.GU59496@kib.kiev.ua> In-Reply-To: <20131229090053.GU59496@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.629899992726084 urlsuspect_oldscore=0.0298999927260837 suspectscore=4 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=9.48027711888955e-10 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=498 rbsscore=0.629899992726084 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312290139 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org, Nathan Whitehorn X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 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: Sun, 29 Dec 2013 19:25:48 -0000 On 12/29/2013 03:00, Konstantin Belousov wrote: > On Sat, Dec 28, 2013 at 06:49:25PM -0600, Alan Cox wrote: >> On 12/28/2013 18:02, Nathan Whitehorn wrote: >>> On 12/26/13 00:46, Marcel Moolenaar wrote: >>>> Author: marcel >>>> Date: Thu Dec 26 05:46:10 2013 >>>> New Revision: 259908 >>>> URL: http://svnweb.freebsd.org/changeset/base/259908 >>>> >>>> Log: >>>> For ia64, use pmap_remove_pages() and not pmap_remove(). The problem is >>>> that we don't have a good way (yet) to iterate over the mapped pages by >>>> virtual address and simply try each page within the range. Given that we >>>> call pmap_remove() over the entire 2^63 bytes of address space, it takes >>>> a while for pmap_remove to have tried all 2^50 pages. >>>> By using pmap_remove_pages() we use the PV list to find all mappings. >>>> >>>> Change derived from a patch by: alc >>>> >>> Why make this ia64-specific? It seems like a potentially useful general >>> optimization and certainly shouldn't be harmful on other architectures. >> Some of the other implementations of pmap_remove_pages() have >> limitations that don't permit them to be used for this purpose, e.g., >> >> if (pmap != PCPU_GET(curpmap)) { >> printf("warning: pmap_remove_pages called with >> non-current pmap\n"); >> return; >> } > BTW, I do not easily see why the current amd64 implementation needs > the pmap being current. I do not see accesses to recursive page table > mappings in the code. The amd64 implementation doesn't load and clear the PTEs atomically, so the dirty bit could be set by another processor after the PTE was loaded but before it was cleared. Alan