From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NqVRH-0000c9-L2 for qemu-devel@nongnu.org; Sat, 13 Mar 2010 12:47:51 -0500 Received: from [199.232.76.173] (port=53446 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NqVRH-0000c1-8X for qemu-devel@nongnu.org; Sat, 13 Mar 2010 12:47:51 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NqVRG-0000rs-0X for qemu-devel@nongnu.org; Sat, 13 Mar 2010 12:47:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45809) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NqVRF-0000ro-Ji for qemu-devel@nongnu.org; Sat, 13 Mar 2010 12:47:49 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2DHllG5019415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 13 Mar 2010 12:47:48 -0500 Date: Sat, 13 Mar 2010 18:47:46 +0100 From: Andrea Arcangeli Subject: Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support Message-ID: <20100313174746.GG5677@random.random> References: <20100311151427.GE5677@random.random> <4B9911B0.5000302@redhat.com> <20100311160505.GG5677@random.random> <4B9B4CB0.7080200@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9B4CB0.7080200@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org On Sat, Mar 13, 2010 at 10:28:32AM +0200, Avi Kivity wrote: > On 03/11/2010 06:05 PM, Andrea Arcangeli wrote: > > On Thu, Mar 11, 2010 at 05:52:16PM +0200, Avi Kivity wrote: > > > >> That is a little wasteful. How about a hint to mmap() requesting proper > >> alignment (MAP_HPAGE_ALIGN)? > >> > > So you suggest adding a new kernel feature to mmap? Not sure if it's > > worth it, considering it'd also increase the number of vmas because it > > will have to leave an hole. Wasting 2M-4k of virtual memory is likely > > cheaper than having 1 more vma in the rbtree for every page fault. So > > I think it's better to just malloc and adjust ourselfs on the next > > offset which is done in userland by qemu_memalign I think. > > > > > > Won't we get a new vma anyway due to the madvise() call later? As long as MADV_HUGEPAGE is set in all, it will merge the vmas together. So if we do stuff like "alloc from 0 to 4G-4k" and then alloc "4G to 8G" this will avoid a vma split. (initially the mmap will create a vma, but it'll be immediately removed from madvise with vma_merge) > But I agree it isn't worth it. 2 vma or 1 vma isn't measurable of course, but yes the point is that it's not worth it because doing it in userland is theoretically better too for performance.