From owner-svn-src-head@FreeBSD.ORG Fri Jul 19 20:30:40 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BF5D419; Fri, 19 Jul 2013 20:30:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 59BA7F71; Fri, 19 Jul 2013 20:30:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4B101B91C; Fri, 19 Jul 2013 16:30:39 -0400 (EDT) From: John Baldwin To: src-committers@freebsd.org Subject: Re: svn commit: r253471 - in head/sys: dev/drm2/i915 kern vm Date: Fri, 19 Jul 2013 16:30:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307191906.r6JJ6GaV006994@svn.freebsd.org> In-Reply-To: <201307191906.r6JJ6GaV006994@svn.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201307191630.31428.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Jul 2013 16:30:39 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:30:40 -0000 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