From mboxrd@z Thu Jan 1 00:00:00 1970 From: Izik Eidus Subject: Re: [PATCH 3/4] Swapping Date: Mon, 15 Oct 2007 22:03:15 +0200 Message-ID: <4713C783.7080806@qumranet.com> References: <47102919.6070802@qumranet.com> <471124D4.3090901@codemonkey.ws> <471126D9.4030204@qumranet.com> <47112D66.4020500@qumranet.com> <47115207.3090909@codemonkey.ws> <4711542F.2060306@qumranet.com> <4711563D.8020000@codemonkey.ws> <471156D9.3030700@qumranet.com> <47116486.4070609@codemonkey.ws> <4713BED9.7000302@codemonkey.ws> <4713C700.5010304@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <4713C700.5010304-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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 Izik Eidus wrote: > Anthony Liguori wrote: >> Anthony Liguori wrote: >>> Izik Eidus wrote: >>>> Anthony Liguori wrote: >>>>> >>>>> I think it's just a matter of calling do_mmap() with the >>>>> appropriate parameters. It looks likes there's some drivers call >>>>> do_mmap() directly. >>>>> >>>> yea, i think you right, this is excellent idea!, when we will merge >>>> the swapping to kvm, we will add swapping support to older userspace. >>> >>> Here's a patch against your series. The memset in kvmctl ends up >>> making the guest use all physical memory to start off with but I did >>> confirm that once the system is under memory pressure, the guest's >>> memory becomes swappable. Of course, it's quite painful :-) >>> >>> A nice thing though is that a lot of the code becomes a bit cleaner >>> and we can eliminate the phys_mem array entirely. >> >>> /* Allocate if a slot is being created */ >>> - if (npages && !new.phys_mem) { >>> - new.phys_mem = vmalloc(npages * sizeof(struct page *)); >>> - >>> - if (!new.phys_mem) >>> - goto out_unlock; >>> - >>> + if (npages) { >> >> This is wrong apparently. We needed to have new.phys_mem to indicate >> whether the slot has been created yet or not. The new attached patch >> uses new.rmap instead of new.phys_mem to accomplish the same goal. >> > this patch look good, and indeed make all the things simple. > but why you didnt use new.phys_mem ? >> I no longer see the BUG() that I was seeing. >> >>> Regards, >>> >>> Anthony Liguori >>> >>> >> upsss ignore me:) i am idiot: :) > > ------------------------------------------------------------------------- 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/