Date: Fri, 19 Jul 2013 16:30:31 -0400 From: John Baldwin <jhb@freebsd.org> To: src-committers@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r253471 - in head/sys: dev/drm2/i915 kern vm Message-ID: <201307191630.31428.jhb@freebsd.org> In-Reply-To: <201307191906.r6JJ6GaV006994@svn.freebsd.org> References: <201307191906.r6JJ6GaV006994@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307191630.31428.jhb>