From owner-svn-src-all@FreeBSD.ORG Thu Sep 9 17:19:11 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80B8E10656D3; Thu, 9 Sep 2010 17:19:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 542C08FC17; Thu, 9 Sep 2010 17:19:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L8H00A16MNPDT00@smtpauth3.wiscmail.wisc.edu>; Thu, 09 Sep 2010 11:19:01 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.10]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L8H00457MNNRP90@smtpauth3.wiscmail.wisc.edu>; Thu, 09 Sep 2010 11:18:59 -0500 (CDT) Date: Thu, 09 Sep 2010 11:18:58 -0500 From: Nathan Whitehorn In-reply-to: <4C8904E3.9000907@rice.edu> To: Alan Cox Message-id: <4C8908F2.6050806@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.10 X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.9.9.160915, SenderIP=76.210.68.10 X-Enigmail-Version: 1.0.1 References: <201009091332.o89DWw9H087769@svn.freebsd.org> <4C8904E3.9000907@rice.edu> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100729 Thunderbird/3.0.6 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212360 - head/sys/vm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 09 Sep 2010 17:19:11 -0000 On 09/09/10 11:01, Alan Cox wrote: > Nathan Whitehorn wrote: >> Author: nwhitehorn >> Date: Thu Sep 9 13:32:58 2010 >> New Revision: 212360 >> URL: http://svn.freebsd.org/changeset/base/212360 >> >> Log: >> On architectures with non-tree-based page tables like PowerPC, >> every page >> in a range must be checked when calling pmap_remove(). Calling >> pmap_remove() from vm_pageout_map_deactivate_pages() with the >> entire range >> of the map could result in attempting to demap an extraordinary number >> of pages (> 10^15), so iterate through each map entry and unmap >> each of >> them individually. >> > > This is a machine-dependent issue, and so I will argue that it is the > pmap's and not the machine-independent layer's responsibility to deal > with this. Our sparc64 port faces the same problem with the TSB, and > it deals with it internally. Moreover, the solution isn't that > complicated. Is there any reason why the sparc64 solution can't be > applied to powerpc? > > Regards, > Alan > It's really a pain. You have to either search the entire hashed page table after transforming the ranges from effective addresses into virtual addresses (and into a discontiguous set of ranges), which involves sorting through several hundred thousand or more entries, or every pmap needs to maintain a list of pages that belong to it at all times, which starts to duplicate the functionality of vm_map, as far as I understand it. The second approach seems to be the one followed by sparc64 (though I'm not very familiar with sparc64's pmap). This particular code seems to be the only place in the kernel that does giant deallocations or protection changes, and I didn't see a reason why this code would be any less efficient on architectures with tree-based tables than the previous one, so it seemed to minimize the number of required hacks just to change it here. If it actually is worse on x86, I'm happy to revert the change and try to hack around this in pmap. -Nathan