From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 12 16:24:45 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18D4C106564A; Wed, 12 Oct 2011 16:24:45 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id C93538FC0A; Wed, 12 Oct 2011 16:24:44 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 033BA291B9E; Wed, 12 Oct 2011 11:24:44 -0500 (CDT) X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no Received: from proofpoint2.rice.edu (proofpoint2.rice.edu [128.42.182.232]) by mh2.mail.rice.edu (Postfix) with ESMTP id D3B22291B9C; Wed, 12 Oct 2011 11:24:43 -0500 (CDT) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by proofpoint2.rice.edu (8.14.4/8.14.4) with ESMTP id p9CGOhPf021221; Wed, 12 Oct 2011 11:24:43 -0500 Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 9B2CD297603; Wed, 12 Oct 2011 11:24:43 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id EpwOS-gYTnfS; Wed, 12 Oct 2011 11:24:43 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id E5BC3291976; Wed, 12 Oct 2011 11:24:42 -0500 (CDT) Message-ID: <4E95BF4A.1060706@rice.edu> Date: Wed, 12 Oct 2011 11:24:42 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Tinguely References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> <4E946AFA.6060105@rice.edu> <4E947E85.2040103@gmail.com> In-Reply-To: <4E947E85.2040103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Oct 2011 16:37:14 +0000 Cc: alc@freebsd.org, Wojciech Puchar , Kostik Belousov , hackers@freebsd.org, Grzegorz Kulewski Subject: Re: mmap performance and memory use X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:24:45 -0000 On 10/11/2011 12:36, Mark Tinguely wrote: > On 10/11/2011 11:12 AM, Alan Cox wrote: >> On 10/10/2011 16:28, Wojciech Puchar wrote: >>> is it possible to force VM subsystem to operate on superpages when >>> possible - i mean swapping in 2MB chunks? >>> >> >> Currently, no. For some applications, like the Sun/Oracle JVM, that >> have code to explicitly manage large pages, there could be some >> benefit in the form of reduced overhead. So, it's on my "to do" >> list, but no where near the top of that list. >> >> Alan >> > > Am I correct in remembering that super-pages have to be aligned on the > super-page boundary and be contiguous? > Yes. However, if you allocate (or mmap(2)) a large range of virtual memory, e.g., 10 MB, and the start of that range is not aligned on a superpage boundary, the virtual memory system can still promote the four 2 MB sized superpages in the middle of that range. > If so, in the mmap(), he may want to include the 'MAP_FIXED' flag with > an address that is on a super-page boundary. Right now, the > "VMFS_ALIGNED_SPACE" that does the VA super-page alignment is only > used for device pagers. > Yes. More precisely, the second, third, etc. mmap(2) should duplicate the alignment of the first mmap(2). In fact, this is what VMFS_ALIGNED_SPACE does. It looks at the alignment of the pages already allocated to the file (or vm object) and attempts to duplicate that alignment. Sooner or later, I will probably make VMFS_ALIGNED_SPACE the default for file types other than devices. > Similarly, if the allocated physical pages for the object are not > contiguous, then MAP_PREFAULT_READ will not result in a super-page > promotion. > As described in my earlier e-mail on this topic, in this case, I call these superpage mappings and not superpage promotions, because the virtual system creates a large page mapping, e.g., a 2 MB page table entry, from the start. It does not create small page mappings and then promote them to a large page mapping. Alan