Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752644AbcDVBgZ (ORCPT ); Thu, 21 Apr 2016 21:36:25 -0400 Received: from mga09.intel.com ([134.134.136.24]:47587 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751603AbcDVBgY convert rfc822-to-8bit (ORCPT ); Thu, 21 Apr 2016 21:36:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,515,1455004800"; d="scan'208";a="950384554" From: "Li, Liang Z" To: "Michael S. Tsirkin" CC: Rik van Riel , "viro@zeniv.linux.org.uk" , "linux-kernel@vger.kernel.org" , "quintela@redhat.com" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "dgilbert@redhat.com" , "linux-mm@kvack.org" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "agraf@suse.de" , "borntraeger@de.ibm.com" Subject: RE: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap Thread-Topic: [PATCH kernel 1/2] mm: add the related functions to build the free page bitmap Thread-Index: AQHRmknpgl1kdv1qZESOs9NZnESE3J+Q3AOAgACHhcD//48GAIABHYtggAHeTQCAAUQ3QA== Date: Fri, 22 Apr 2016 01:36:15 +0000 Message-ID: References: <1461076474-3864-1-git-send-email-liang.z.li@intel.com> <1461076474-3864-2-git-send-email-liang.z.li@intel.com> <1461077659.3200.8.camel@redhat.com> <20160419191111-mutt-send-email-mst@redhat.com> <20160421134854.GA6858@redhat.com> In-Reply-To: <20160421134854.GA6858@redhat.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjA4NDlmNWYtN2Q0Zi00YmY4LWI1ODQtMjU4N2UxMDhlMzBhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InJoRnB3b1wveFIwc3VmT2kyMXRxeHU3a0V6cWpMK0dXYTlIdzJ1Zlc4UERrPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2763 Lines: 68 > On Wed, Apr 20, 2016 at 01:41:24AM +0000, Li, Liang Z wrote: > > > Cc: Rik van Riel; viro@zeniv.linux.org.uk; > > > linux-kernel@vger.kernel.org; quintela@redhat.com; > > > amit.shah@redhat.com; pbonzini@redhat.com; dgilbert@redhat.com; > > > linux-mm@kvack.org; kvm@vger.kernel.org; qemu- devel@nongnu.org; > > > agraf@suse.de; borntraeger@de.ibm.com > > > Subject: Re: [PATCH kernel 1/2] mm: add the related functions to > > > build the free page bitmap > > > > > > On Tue, Apr 19, 2016 at 03:02:09PM +0000, Li, Liang Z wrote: > > > > > On Tue, 2016-04-19 at 22:34 +0800, Liang Li wrote: > > > > > > The free page bitmap will be sent to QEMU through virtio > > > > > > interface and used for live migration optimization. > > > > > > Drop the cache before building the free page bitmap can get > > > > > > more free pages. Whether dropping the cache is decided by user. > > > > > > > > > > > > > > > > How do you prevent the guest from using those recently-freed > > > > > pages for something else, between when you build the bitmap and > > > > > the live migration completes? > > > > > > > > Because the dirty page logging is enabled before building the > > > > bitmap, there is no need to prevent the guest from using the > > > > recently-freed > > > pages ... > > > > > > > > Liang > > > > > > Well one point of telling host that page is free is so that it can > > > mark it clean even if it was dirty previously. > > > So I think you must pass the pages to guest under the lock. > > > > Thanks! You mean save the free page bitmap in host pages? > > No, I literally mean don't release &zone->lock before you pass the list of > pages to host. > > > > This will allow host optimizations such as marking these pages > > > MADV_DONTNEED or MADV_FREE Otherwise it's all too tied up to a > > > specific usecase - you aren't telling host that a page is free, you > > > are telling it that a page was free in the past. > > > > > > > Then we should prevent the guest from using those recently-freed > > pages, before doing the MADV_DONTNEED or MADV_FREE, or the pages in > > the free page bitmap may be not free any more. In which case we will > > do something like this? Balloon? > > > > Liang > > > > Wouldn't keeping &zone->lock make sure these pages aren't used? > > Yes, keep the &zone->lock can ensure this, and it can make sure we get a real free page bitmap, its more semantic correct. But once we get a 'real' free page bitmap, the pages in the free page bitmap may became no free anymore before using it for some purposes, is there any mechanism to prevent this? If there is no strong reason, it's better to take the lock as short as possible. Could you elaborate some use cases which require a 'real' free page bitmap? Liang > > > -- > > > MST