svn commit: r259908 - head/sys/vm

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20131229/d1d76c3d/attachment.sig>