From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: the trouble with large pages Date: Fri, 07 Sep 2007 10:02:53 -0500 Message-ID: <1189177373.18157.0.camel@squirrel> References: <1189176020.9287.18.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel , kvm-devel To: Hollis Blanchard Return-path: In-Reply-To: <1189176020.9287.18.camel@basalt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Fri, 2007-09-07 at 09:40 -0500, Hollis Blanchard wrote: > The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. > When we run that as a guest, those pages would of course need to be > physically contiguous in the host. > > I think long-term the KVM plan is to move memory allocation out of the > kernel (where it currently uses vmalloc) into userspace, with the idea > being that userspace could allocate memory via hugetlbfs. Anybody tried > hugetlbfs on 440 or e500? > > A poor-man's equivalent might be to limit the host memory to e.g. 256MB, > then have userspace mmap(/dev/ram) starting there. > > Another possibility is to fake out guest large pages by actually using > small pages on the host, and handle the extra faults in KVM without > notifying the guest. This is what is done on x86. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/