svn commit: r259908 - head/sys/vm

Alan Cox alc at rice.edu
Sun Dec 29 19:25:48 UTC 2013


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



More information about the svn-src-all mailing list