From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O1Kwp-0006EB-7t
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:49:11 -0400
Received: from [140.186.70.92] (port=43572 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O1Kwm-0006Cb-VK
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:49:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <rth7680@gmail.com>) id 1O1Kwm-0000fY-27
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:49:08 -0400
Received: from mail-ew0-f227.google.com ([209.85.219.227]:50566)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <rth7680@gmail.com>) id 1O1Kwl-0000fM-TN
	for qemu-devel@nongnu.org; Mon, 12 Apr 2010 10:49:08 -0400
Received: by ewy27 with SMTP id 27so1956996ewy.10
	for <qemu-devel@nongnu.org>; Mon, 12 Apr 2010 07:49:06 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <4BC332CD.2060904@twiddle.net>
Date: Mon, 12 Apr 2010 07:48:45 -0700
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Host vs Guest memory allocation
References: <4BBA6803.3000008@twiddle.net>
	<201004121225.18070.paul@codesourcery.com>
In-Reply-To: <201004121225.18070.paul@codesourcery.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

On 04/12/2010 04:25 AM, Paul Brook wrote:
>> (1) Enable softmmu for userland. This is of course the highest overhead,
>>      but will work for all combinations.
>
> This has a significant performance hit, and gets very tricky for things like
> mmaped files.

It has the advantage of actually working for several cases of 64-on-32
that simply don't at the moment.  MMap is tricky, but no more than 
usual.  We still have problems with partial pages mapped past the end
of the file when host page size > target page size.

>> (2) Pre-allocate the entire guest address space in the host.  With
>>      Linux mmap w/ MAP_NORESERVE or Windows VirtualAlloc w/ MEM_RESERVE
>>      and a possibly reduced guest address space this is doesn't seem so bad.
>
> This breaks if the host sets ulimit -v.

Yes, but we'd know that immediately at startup.  This is why I 
recommended implementing multiple solutions and falling back from one to 
the other when we find they don't work.


r~