From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58746 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pauxh-0005h6-9b for qemu-devel@nongnu.org; Thu, 06 Jan 2011 13:53:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PauxS-0000qf-8t for qemu-devel@nongnu.org; Thu, 06 Jan 2011 13:53:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PauxS-0000qP-11 for qemu-devel@nongnu.org; Thu, 06 Jan 2011 13:53:10 -0500 Date: Thu, 6 Jan 2011 18:49:25 +0100 From: Andrea Arcangeli Subject: Re: [Qemu-devel] [PATCH] add MADV_DONTFORK to guest physical memory Message-ID: <20110106174925.GK15823@random.random> References: <20100915170824.GL5981@random.random> <20110105151012.GC15823@random.random> <4D24B22C.4010302@linux.vnet.ibm.com> <20110105195430.GF15823@random.random> <4D24D3EB.1080702@linux.vnet.ibm.com> <20110105203518.GH15823@random.random> <4D24E249.2040501@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D24E249.2040501@linux.vnet.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Blue Swirl , Andreas =?iso-8859-1?Q?F=E4rber?= , "qemu-devel@nongnu.org Developers" , Anthony Liguori , Alexander Graf On Wed, Jan 05, 2011 at 03:27:37PM -0600, Michael Roth wrote: > On 01/05/2011 02:35 PM, Andrea Arcangeli wrote: > > On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote: > >> Yah you're right, but I've seen several discussions about using mempath > >> for tmpfs/ram-backed files for things like numa/zram/etc so tend to > >> think of it as something potentially more than just a hook for > >> hugetlbfs, which is becoming less and less useful. But the MADV_DONTFORK > >> stuff should still be immediately applicable. > > > > Yes, MADV_DONTFORK should be set all on all guest physical memory > > without options so I hope the new patch I just posted is fine to stop > > the spurious -ENOMEM failures in fork. > > The patch in this thread? A couple paths still aren't covered when using > -mem-path. Something like this should get them all: Well the reason of MADV_DONTFORK is to avoid accounting issues with anonymous memory, mem-path don't have that issue as hugetlbfs skips the accounting (it has to because hugetlbfs are not always taken from the regular page allocator). It could be however considered a minor performance optimization. Now you mention that you want to use -mem-path for other things too, so maybe that's why you need it there too. BTW, if you ever need it for more than hugetlbfs, I'm afraid this MAP_PRIVATE I see when mem_prealloc isn't set, is going to screw any other potential useful usage besides hugetlbfs, not exactly sure why it makes any sense to use MAP_PRIVATE there and not only MAP_SHARED.