From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v11 4/6] mm: function to offer a page block on the free list Date: Mon, 12 Jun 2017 23:34:06 +0300 Message-ID: <20170612194438-mutt-send-email-mst@kernel.org> References: <1497004901-30593-1-git-send-email-wei.w.wang@intel.com> <1497004901-30593-5-git-send-email-wei.w.wang@intel.com> <20170612181354-mutt-send-email-mst@kernel.org> <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Dave Hansen Cc: aarcange@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, amit.shah@redhat.com, liliang.opensource@gmail.com, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, cornelia.huck@de.ibm.com, pbonzini@redhat.com, akpm@linux-foundation.org, mgorman@techsingularity.net List-Id: virtualization@lists.linuxfoundation.org On Mon, Jun 12, 2017 at 09:42:36AM -0700, Dave Hansen wrote: > On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote: > > > >> The hypervisor is going to throw away the contents of these pages, > >> right? > > It should be careful and only throw away contents that was there before > > report_unused_page_block was invoked. Hypervisor is responsible for not > > corrupting guest memory. But that's not something an mm patch should > > worry about. > > That makes sense. I'm struggling to imagine how the hypervisor makes > use of this information, though. Does it make the pages read-only > before this, and then it knows if there has not been a write *and* it > gets notified via this new mechanism that it can throw the page away? Yes, and specifically, this is how it works for migration. Normally you start by migrating all of memory, then send updates incrementally if pages have been modified. This mechanism allows skipping some pages in the 1st stage, if they get changed they will be migrated in the 2nd stage. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) by kanga.kvack.org (Postfix) with ESMTP id 05F216B0292 for ; Mon, 12 Jun 2017 16:34:13 -0400 (EDT) Received: by mail-qt0-f197.google.com with SMTP id u51so18265325qte.15 for ; Mon, 12 Jun 2017 13:34:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id o21si9725687qtf.242.2017.06.12.13.34.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 13:34:10 -0700 (PDT) Date: Mon, 12 Jun 2017 23:34:06 +0300 From: "Michael S. Tsirkin" Subject: Re: [PATCH v11 4/6] mm: function to offer a page block on the free list Message-ID: <20170612194438-mutt-send-email-mst@kernel.org> References: <1497004901-30593-1-git-send-email-wei.w.wang@intel.com> <1497004901-30593-5-git-send-email-wei.w.wang@intel.com> <20170612181354-mutt-send-email-mst@kernel.org> <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: Dave Hansen Cc: Wei Wang , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, david@redhat.com, cornelia.huck@de.ibm.com, akpm@linux-foundation.org, mgorman@techsingularity.net, aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, liliang.opensource@gmail.com On Mon, Jun 12, 2017 at 09:42:36AM -0700, Dave Hansen wrote: > On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote: > > > >> The hypervisor is going to throw away the contents of these pages, > >> right? > > It should be careful and only throw away contents that was there before > > report_unused_page_block was invoked. Hypervisor is responsible for not > > corrupting guest memory. But that's not something an mm patch should > > worry about. > > That makes sense. I'm struggling to imagine how the hypervisor makes > use of this information, though. Does it make the pages read-only > before this, and then it knows if there has not been a write *and* it > gets notified via this new mechanism that it can throw the page away? Yes, and specifically, this is how it works for migration. Normally you start by migrating all of memory, then send updates incrementally if pages have been modified. This mechanism allows skipping some pages in the 1st stage, if they get changed they will be migrated in the 2nd stage. -- MST -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbdFLUeM (ORCPT ); Mon, 12 Jun 2017 16:34:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33108 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752658AbdFLUeK (ORCPT ); Mon, 12 Jun 2017 16:34:10 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7893F4E040 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mst@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7893F4E040 Date: Mon, 12 Jun 2017 23:34:06 +0300 From: "Michael S. Tsirkin" To: Dave Hansen Cc: Wei Wang , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, david@redhat.com, cornelia.huck@de.ibm.com, akpm@linux-foundation.org, mgorman@techsingularity.net, aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, liliang.opensource@gmail.com Subject: Re: [PATCH v11 4/6] mm: function to offer a page block on the free list Message-ID: <20170612194438-mutt-send-email-mst@kernel.org> References: <1497004901-30593-1-git-send-email-wei.w.wang@intel.com> <1497004901-30593-5-git-send-email-wei.w.wang@intel.com> <20170612181354-mutt-send-email-mst@kernel.org> <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 12 Jun 2017 20:34:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 12, 2017 at 09:42:36AM -0700, Dave Hansen wrote: > On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote: > > > >> The hypervisor is going to throw away the contents of these pages, > >> right? > > It should be careful and only throw away contents that was there before > > report_unused_page_block was invoked. Hypervisor is responsible for not > > corrupting guest memory. But that's not something an mm patch should > > worry about. > > That makes sense. I'm struggling to imagine how the hypervisor makes > use of this information, though. Does it make the pages read-only > before this, and then it knows if there has not been a write *and* it > gets notified via this new mechanism that it can throw the page away? Yes, and specifically, this is how it works for migration. Normally you start by migrating all of memory, then send updates incrementally if pages have been modified. This mechanism allows skipping some pages in the 1st stage, if they get changed they will be migrated in the 2nd stage. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dKW2S-0006EA-1g for qemu-devel@nongnu.org; Mon, 12 Jun 2017 16:34:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dKW2N-00007Q-4v for qemu-devel@nongnu.org; Mon, 12 Jun 2017 16:34:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8797) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dKW2M-000075-V4 for qemu-devel@nongnu.org; Mon, 12 Jun 2017 16:34:11 -0400 Date: Mon, 12 Jun 2017 23:34:06 +0300 From: "Michael S. Tsirkin" Message-ID: <20170612194438-mutt-send-email-mst@kernel.org> References: <1497004901-30593-1-git-send-email-wei.w.wang@intel.com> <1497004901-30593-5-git-send-email-wei.w.wang@intel.com> <20170612181354-mutt-send-email-mst@kernel.org> <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d0900f3-9df5-ac63-4069-2d796f2a5bc7@intel.com> Subject: Re: [Qemu-devel] [PATCH v11 4/6] mm: function to offer a page block on the free list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dave Hansen Cc: Wei Wang , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, david@redhat.com, cornelia.huck@de.ibm.com, akpm@linux-foundation.org, mgorman@techsingularity.net, aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com, liliang.opensource@gmail.com On Mon, Jun 12, 2017 at 09:42:36AM -0700, Dave Hansen wrote: > On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote: > > > >> The hypervisor is going to throw away the contents of these pages, > >> right? > > It should be careful and only throw away contents that was there before > > report_unused_page_block was invoked. Hypervisor is responsible for not > > corrupting guest memory. But that's not something an mm patch should > > worry about. > > That makes sense. I'm struggling to imagine how the hypervisor makes > use of this information, though. Does it make the pages read-only > before this, and then it knows if there has not been a write *and* it > gets notified via this new mechanism that it can throw the page away? Yes, and specifically, this is how it works for migration. Normally you start by migrating all of memory, then send updates incrementally if pages have been modified. This mechanism allows skipping some pages in the 1st stage, if they get changed they will be migrated in the 2nd stage. -- MST