From mboxrd@z Thu Jan 1 00:00:00 1970 From: john cooper Subject: Re: Resend: patch: qemu + hugetlbfs.. Date: Wed, 27 Aug 2008 00:13:34 -0400 Message-ID: <48B4D46E.4010503@redhat.com> References: <4873E400.4000409@third-harmonic.com> <4873F395.6030209@codemonkey.ws> <4874051A.8000802@third-harmonic.com> <48740F86.3050306@codemonkey.ws> <20080709170301.GA11439@dmt.cnet> <4874F156.2010708@codemonkey.ws> <48763B86.6060402@third-harmonic.com> <48764DAF.6060502@codemonkey.ws> <48766E03.4090901@third-harmonic.com> <48767558.50301@codemonkey.ws> <48767B20.20806@third-harmonic.com> <4876815E.3010109@codemonkey.ws> <48B33AAD.8000508@third-harmonic.com> <48B3BAC6.90903@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john cooper , kvm@vger.kernel.org, Anthony Liguori , Marcelo Tosatti , john.cooper@redhat.com To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:52740 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750775AbYH0ESV (ORCPT ); Wed, 27 Aug 2008 00:18:21 -0400 In-Reply-To: <48B3BAC6.90903@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > john cooper wrote: >> This patch from over a month ago doesn't seem to have >> made it into kvm-73 and may have been lost in the >> shuffle. Attached is essentially the same patch but >> as applied to kvm-73, and validated relative to that >> version. >> > > What is the motivation for providing an option to disable this? If we > can detect mem-path is backed by huge pages somehow, I think we can > prefault the memory unconditionally. > Pre-allocation of the entire huge page backed guest memory avoids the nondeterministic termination but admittedly is overly pessimistic. As this patch does so by default when -mem-path is specified, allowing for disable of pre-allocation simply reverts this change to prior behavior for use cases more tolerant to it as well as for debug purposes. The real fix arguably hinges on huge pages having more general virtual memory behavior. But that appears to be a much longer term prospect. -john -- john.cooper@redhat.com