svn commit: r212360 - head/sys/vm

Nathan Whitehorn nwhitehorn at freebsd.org
Thu Sep 9 17:19:11 UTC 2010


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


More information about the svn-src-all mailing list