From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [PATCH 1/2] kvm tools: Add memory gap for larger RAM sizes Date: Wed, 11 May 2011 09:26:08 +0300 Message-ID: <4DCA2C00.9090907@cs.helsinki.fi> References: <1305061513-28360-1-git-send-email-levinsasha928@gmail.com> <1305094876.2249.2.camel@sasha> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mingo@elte.hu, asias.hejun@gmail.com, prasadjoshi124@gmail.com, avi@redhat.com, gorcunov@gmail.com, kvm@vger.kernel.org To: Sasha Levin Return-path: Received: from courier.cs.helsinki.fi ([128.214.9.1]:36841 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755282Ab1EKQ4f (ORCPT ); Wed, 11 May 2011 12:56:35 -0400 In-Reply-To: <1305094876.2249.2.camel@sasha> Sender: kvm-owner@vger.kernel.org List-ID: On 5/11/11 9:21 AM, Sasha Levin wrote: > If you feel the 512MB vs guest_flat_to_host() trade-off is worth it, > I'll change it to work that way. Why would it not be? This is 64-bit only, right? There's plenty of virtual address space and mprotect() should make sure we never allocate physical pages for it. Sure, there's some in-kernel overhead involved as well, but that's extremely small. I'm not worried about performance in guest_flat_to_host() but I think the current implementation is not very clean. If you want to mmap() two separate regions, we should have our own internal "memory map" that's used for this (and for populating KVM end E820 maps). So I think mmap'ing the gap is the cleanest solution for now. We can revisit the decision if we need even more regions in the future. Pekka