Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Dec 2013 21:40:45 -0500
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Alan Cox <alc@rice.edu>, Marcel Moolenaar <marcel@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r259908 - head/sys/vm
Message-ID:  <52BF8BAD.40503@freebsd.org>
In-Reply-To: <52BF7195.2070606@rice.edu>
References:  <201312260546.rBQ5kAoJ009798@svn.freebsd.org> <52BF6699.1040006@freebsd.org> <52BF7195.2070606@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/28/13 19:49, 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;
>         }
>
> Alan
>

Fair enough. Thanks for the explanation.
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52BF8BAD.40503>