From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: (no subject) Date: Mon, 13 Aug 2007 11:10:30 +0300 Message-ID: <46C011F6.7070201@qumranet.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <1186954667.9418.19.camel@squirrel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Izik Eidus , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <1186954667.9418.19.camel@squirrel> 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 Anthony Liguori wrote: > Hi Izik, > > On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote: > >> we are working on swapping support for the guests in kvm. >> we want to allow management of the memory swapping of the guests from >> kvm. >> >> i wrote this patch that move the guest allocated memory from the >> kernel to the userspace for better management. >> plus in this way it will share more code for such soultion with s390 >> and other archs. >> > > Do we care much about maintaining the kvmctl API? Not so much at this time. We will later on (it will also be a dynamic library at that time). > I ask because I think > it would be nice to provide a pointer to kvmctl instead of having it > allocate the memory. I think there are a few advantages to this. > > It simplifies the QEMU patch and it allows for the logic for choosing > how memory is allocated to be done in QEMU. I'm thinking about things > like allocating memory from hugetlbfs. Since large pages are a sparse > commodity, I don't think we want to use large pages unless the user asks > us to. Seems like this logic is best suited to be in QEMU to me. > Yes, that is one of the motivations for this patch. Indeed it is a lot closer than guest paging. However this can be modified later, let's keep this patchset small for now. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/