svn commit: r253471 - in head/sys: dev/drm2/i915 kern vm

[John Baldwin]

On Friday, July 19, 2013 3:06:16 pm John Baldwin wrote:
> Author: jhb
> Date: Fri Jul 19 19:06:15 2013
> New Revision: 253471
> URL: http://svnweb.freebsd.org/changeset/base/253471
> 
> Log:
>   Be more aggressive in using superpages in all mappings of objects:
>   - Add a new address space allocation method (VMFS_OPTIMAL_SPACE) for
>     vm_map_find() that will try to alter the alignment of a mapping to match
>     any existing superpage mappings of the object being mapped.  If no
>     suitable address range is found with the necessary alignment,
>     vm_map_find() will fall back to using the simple first-fit strategy
>     (VMFS_ANY_SPACE).
>   - Change mmap() without MAP_FIXED, shmat(), and the GEM mapping ioctl to
>     use VMFS_OPTIMAL_SPACE instead of VMFS_ANY_SPACE.

In particular, the first mapping of an object that uses superpages establishes
an overall offset within that object of each superpages.  Other mappings of 
the same object can only use superpages if their mappings use the same 
superpage-offset relative to the start of the object.  As a specific example:

Suppose process A maps a file F starting at offset 0 and the address assigned 
by mmap happens to be superpage aligned.  Then, the first superpage-sized 
bytes of F will be stored in a superpage, the second superpage-sized bytes in 
a superpage, etc.

If process B then maps the same file F at offset 0, but mmap() returns an 
address that is not superpage-aligned, then none of the potential superpage
mappings in B can work because the virtual "superpage" addresses are not 
aligned with the physical superpage addresses assigned to F by A's mapping.

What this change does is cause mmap() to first try to find an address that has
the same alignment as A during B's mmap() request so that both processes can 
use superpages for F.

In addition this may alleviate a known performance issue on certain AMD 
processors by forcing virtual aliases of text segments in binaries and shared 
libraries to use the same relative alignment.  The issue is documented in more 
detail here:

http://developer.amd.com/wordpress/media/2012/10/SharedL1InstructionCacheonAMD15hCPU.pdf

-- 
John Baldwin