From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9C2EC43144 for ; Fri, 29 Jun 2018 07:46:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 53F0F27B9D for ; Fri, 29 Jun 2018 07:46:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53F0F27B9D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933722AbeF2Hqb (ORCPT ); Fri, 29 Jun 2018 03:46:31 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56992 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932331AbeF2Hq1 (ORCPT ); Fri, 29 Jun 2018 03:46:27 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CBA3140780C4; Fri, 29 Jun 2018 07:46:25 +0000 (UTC) Received: from [10.36.117.11] (ovpn-117-11.ams2.redhat.com [10.36.117.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 16125111E410; Fri, 29 Jun 2018 07:46:10 +0000 (UTC) Subject: Re: [PATCH v34 0/4] Virtio-balloon: support free page reporting To: Wei Wang , virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com, mhocko@kernel.org, akpm@linux-foundation.org Cc: torvalds@linux-foundation.org, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com, peterx@redhat.com, Andrea Arcangeli , Luiz Capitulino References: <1529928312-30500-1-git-send-email-wei.w.wang@intel.com> <5B35ACD5.4090800@intel.com> From: David Hildenbrand Openpgp: preference=signencrypt Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwX4EEwECACgFAljj9eoCGwMFCQlmAYAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEE3eEPcA/4Na5IIP/3T/FIQMxIfNzZshIq687qgG 8UbspuE/YSUDdv7r5szYTK6KPTlqN8NAcSfheywbuYD9A4ZeSBWD3/NAVUdrCaRP2IvFyELj xoMvfJccbq45BxzgEspg/bVahNbyuBpLBVjVWwRtFCUEXkyazksSv8pdTMAs9IucChvFmmq3 jJ2vlaz9lYt/lxN246fIVceckPMiUveimngvXZw21VOAhfQ+/sofXF8JCFv2mFcBDoa7eYob s0FLpmqFaeNRHAlzMWgSsP80qx5nWWEvRLdKWi533N2vC/EyunN3HcBwVrXH4hxRBMco3jvM m8VKLKao9wKj82qSivUnkPIwsAGNPdFoPbgghCQiBjBe6A75Z2xHFrzo7t1jg7nQfIyNC7ez MZBJ59sqA9EDMEJPlLNIeJmqslXPjmMFnE7Mby/+335WJYDulsRybN+W5rLT5aMvhC6x6POK z55fMNKrMASCzBJum2Fwjf/VnuGRYkhKCqqZ8gJ3OvmR50tInDV2jZ1DQgc3i550T5JDpToh dPBxZocIhzg+MBSRDXcJmHOx/7nQm3iQ6iLuwmXsRC6f5FbFefk9EjuTKcLMvBsEx+2DEx0E UnmJ4hVg7u1PQ+2Oy+Lh/opK/BDiqlQ8Pz2jiXv5xkECvr/3Sv59hlOCZMOaiLTTjtOIU7Tq 7ut6OL64oAq+zsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCghCj/CA/lc/LMthqQ773ga uB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseBfDXHA6m4B3mUTWo13nid 0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts6TZ+IrPOwT1hfB4WNC+X 2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiuQmt3yqrmN63V9wzaPhC+ xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKBTccu2AXJXWAE1Xjh6GOC 8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvFFFyAS0Nk1q/7EChPcbRb hJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh2YmnmLRTro6eZ/qYwWkC u8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRkF3TwgucpyPtcpmQtTkWS gDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0LLH63+BrrHasfJzxKXzqg rW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4vq7oFCPsOgwARAQABwsFl BBgBAgAPBQJVy5+RAhsMBQkJZgGAAAoJEE3eEPcA/4NagOsP/jPoIBb/iXVbM+fmSHOjEshl KMwEl/m5iLj3iHnHPVLBUWrXPdS7iQijJA/VLxjnFknhaS60hkUNWexDMxVVP/6lbOrs4bDZ NEWDMktAeqJaFtxackPszlcpRVkAs6Msn9tu8hlvB517pyUgvuD7ZS9gGOMmYwFQDyytpepo YApVV00P0u3AaE0Cj/o71STqGJKZxcVhPaZ+LR+UCBZOyKfEyq+ZN311VpOJZ1IvTExf+S/5 lqnciDtbO3I4Wq0ArLX1gs1q1XlXLaVaA3yVqeC8E7kOchDNinD3hJS4OX0e1gdsx/e6COvy qNg5aL5n0Kl4fcVqM0LdIhsubVs4eiNCa5XMSYpXmVi3HAuFyg9dN+x8thSwI836FoMASwOl C7tHsTjnSGufB+D7F7ZBT61BffNBBIm1KdMxcxqLUVXpBQHHlGkbwI+3Ye+nE6HmZH7IwLwV W+Ajl7oYF+jeKaH4DZFtgLYGLtZ1LDwKPjX7VAsa4Yx7S5+EBAaZGxK510MjIx6SGrZWBrrV TEvdV00F2MnQoeXKzD7O4WFbL55hhyGgfWTHwZ457iN9SgYi1JLPqWkZB0JRXIEtjd4JEQcx +8Umfre0Xt4713VxMygW0PnQt5aSQdMD58jHFxTk092mU+yIHj5LeYgvwSgZN4airXk5yRXl SE+xAvmumFBY Organization: Red Hat GmbH Message-ID: <4840cbb7-dd3f-7540-6a7c-13427de2f0d1@redhat.com> Date: Fri, 29 Jun 2018 09:46:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B35ACD5.4090800@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 29 Jun 2018 07:46:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 29 Jun 2018 07:46:26 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'david@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.06.2018 05:51, Wei Wang wrote: > On 06/27/2018 07:06 PM, David Hildenbrand wrote: >> On 25.06.2018 14:05, Wei Wang wrote: >>> This patch series is separated from the previous "Virtio-balloon >>> Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, >>> implemented by this series enables the virtio-balloon driver to report >>> hints of guest free pages to the host. It can be used to accelerate live >>> migration of VMs. Here is an introduction of this usage: >>> >>> Live migration needs to transfer the VM's memory from the source machine >>> to the destination round by round. For the 1st round, all the VM's memory >>> is transferred. From the 2nd round, only the pieces of memory that were >>> written by the guest (after the 1st round) are transferred. One method >>> that is popularly used by the hypervisor to track which part of memory is >>> written is to write-protect all the guest memory. >>> >>> This feature enables the optimization by skipping the transfer of guest >>> free pages during VM live migration. It is not concerned that the memory >>> pages are used after they are given to the hypervisor as a hint of the >>> free pages, because they will be tracked by the hypervisor and transferred >>> in the subsequent round if they are used and written. >>> >>> * Tests >>> - Test Environment >>> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz >>> Guest: 8G RAM, 4 vCPU >>> Migration setup: migrate_set_speed 100G, migrate_set_downtime 2 second >>> >>> - Test Results >>> - Idle Guest Live Migration Time (results are averaged over 10 runs): >>> - Optimization v.s. Legacy = 284ms vs 1757ms --> ~84% reduction >>> - Guest with Linux Compilation Workload (make bzImage -j4): >>> - Live Migration Time (average) >>> Optimization v.s. Legacy = 1402ms v.s. 2528ms --> ~44% reduction >>> - Linux Compilation Time >>> Optimization v.s. Legacy = 5min6s v.s. 5min12s >>> --> no obvious difference >>> >> Being in version 34 already, this whole thing still looks and feels like >> a big hack to me. It might just be me, but especially if I read about >> assumptions like "QEMU will not hotplug memory during migration". This >> does not feel like a clean solution. >> >> I am still not sure if we really need this interface, especially as real >> free page hinting might be on its way. >> >> a) we perform free page hinting by setting all free pages >> (arch_free_page()) to zero. Migration will detect zero pages and >> minimize #pages to migrate. I don't think this is a good idea but Michel >> suggested to do a performance evaluation and Nitesh is looking into that >> right now. > > The hypervisor doesn't get the zero pages for free. It pays lots of CPU > utilization and memory bandwidth (there are some guys complaining abut > this on the QEMU mailinglist) > In the above results, the legacy part already has the zero page feature > in use. Indeed, I don't consider this attempt not very practical in general, especially as it would rely on KSM right now, which is frowned upon by many people. > >> >> b) we perform free page hinting using something that Nitesh proposed. We >> get in QEMU blocks of free pages that we can MADV_FREE. In addition we >> could e.g. clear the dirty bit of these pages in the dirty bitmap, to >> hinder them from getting migrated. Right now the hinting mechanism is >> synchronous (called from arch_free_page()) but we might be able to >> convert it into something asynchronous. >> >> So we might be able to completely get rid of this interface. And looking >> at all the discussions and problems that already happened during the >> development of this series, I think we should rather look into how clean >> free page hinting might solve the same problem. >> >> If it can't be solved using free page hinting, fair enough. >> > > I'm afraid it can't. For example, when we have a guest booted, without > too many memory activities. Assume the guest has 8GB free memory. The > arch_free_page there won't be able to capture the 8GB free pages since > there is no free() called. This results in no free pages reported to host. So, it takes some time from when the guest boots up until the balloon device was initialized and therefore page hinting can start. For that period, you won't get any arch_free_page()/page hinting callbacks, correct. However in the hypervisor, you can theoretically track which pages the guest actually touched ("dirty"), so you already know "which pages were never touched while booting up until virtio-balloon was brought to life". These, you can directly exclude from migration. No interface required. The remaining problem is pages that were touched ("allocated") by the guest during bootup but freed again, before virtio-balloon came up. One would have to measure how many pages these usually are, I would say it would not be that many (because recently freed pages are likely to be used again next for allocation). However, there are some pages not being reported. During the lifetime of the guest, this should not be a problem, eventually one of these pages would get allocated/freed again, so the problem "solves itself over time". You are looking into the special case of migrating the VM just after it has been started. But we have the exact same problem also for ordinary free page hinting, so we should rather solve that problem. It is not migration specific. If we are looking for an alternative to "problem solves itself", something like "if virtio-balloon comes up, it will report all free pages step by step using free page hinting, just like we would have from "arch_free_pages()"". This would be the same interface we are using for free page hinting - and it could even be made configurable in the guest. The current approach we are discussing internally for details about Nitesh's work ("how the magic inside arch_fee_pages() will work efficiently) would allow this as far as I can see just fine. There would be a tiny little window between virtio-balloon comes up and it has reported all free pages step by step, but that can be considered a very special corner case that I would argue is not worth it to be optimized. If I am missing something important here, sorry in advance :) > > Best, > Wei > -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH v34 0/4] Virtio-balloon: support free page reporting Date: Fri, 29 Jun 2018 09:46:09 +0200 Message-ID: <4840cbb7-dd3f-7540-6a7c-13427de2f0d1@redhat.com> References: <1529928312-30500-1-git-send-email-wei.w.wang@intel.com> <5B35ACD5.4090800@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: yang.zhang.wz@gmail.com, Andrea Arcangeli , riel@redhat.com, quan.xu0@gmail.com, liliang.opensource@gmail.com, Luiz Capitulino , pbonzini@redhat.com, nilal@redhat.com, torvalds@linux-foundation.org To: Wei Wang , virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com, mhocko@kernel.org, akpm@linux-foundation.org Return-path: In-Reply-To: <5B35ACD5.4090800@intel.com> Content-Language: en-US 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 List-Id: kvm.vger.kernel.org On 29.06.2018 05:51, Wei Wang wrote: > On 06/27/2018 07:06 PM, David Hildenbrand wrote: >> On 25.06.2018 14:05, Wei Wang wrote: >>> This patch series is separated from the previous "Virtio-balloon >>> Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, >>> implemented by this series enables the virtio-balloon driver to report >>> hints of guest free pages to the host. It can be used to accelerate live >>> migration of VMs. Here is an introduction of this usage: >>> >>> Live migration needs to transfer the VM's memory from the source machine >>> to the destination round by round. For the 1st round, all the VM's memory >>> is transferred. From the 2nd round, only the pieces of memory that were >>> written by the guest (after the 1st round) are transferred. One method >>> that is popularly used by the hypervisor to track which part of memory is >>> written is to write-protect all the guest memory. >>> >>> This feature enables the optimization by skipping the transfer of guest >>> free pages during VM live migration. It is not concerned that the memory >>> pages are used after they are given to the hypervisor as a hint of the >>> free pages, because they will be tracked by the hypervisor and transferred >>> in the subsequent round if they are used and written. >>> >>> * Tests >>> - Test Environment >>> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz >>> Guest: 8G RAM, 4 vCPU >>> Migration setup: migrate_set_speed 100G, migrate_set_downtime 2 second >>> >>> - Test Results >>> - Idle Guest Live Migration Time (results are averaged over 10 runs): >>> - Optimization v.s. Legacy = 284ms vs 1757ms --> ~84% reduction >>> - Guest with Linux Compilation Workload (make bzImage -j4): >>> - Live Migration Time (average) >>> Optimization v.s. Legacy = 1402ms v.s. 2528ms --> ~44% reduction >>> - Linux Compilation Time >>> Optimization v.s. Legacy = 5min6s v.s. 5min12s >>> --> no obvious difference >>> >> Being in version 34 already, this whole thing still looks and feels like >> a big hack to me. It might just be me, but especially if I read about >> assumptions like "QEMU will not hotplug memory during migration". This >> does not feel like a clean solution. >> >> I am still not sure if we really need this interface, especially as real >> free page hinting might be on its way. >> >> a) we perform free page hinting by setting all free pages >> (arch_free_page()) to zero. Migration will detect zero pages and >> minimize #pages to migrate. I don't think this is a good idea but Michel >> suggested to do a performance evaluation and Nitesh is looking into that >> right now. > > The hypervisor doesn't get the zero pages for free. It pays lots of CPU > utilization and memory bandwidth (there are some guys complaining abut > this on the QEMU mailinglist) > In the above results, the legacy part already has the zero page feature > in use. Indeed, I don't consider this attempt not very practical in general, especially as it would rely on KSM right now, which is frowned upon by many people. > >> >> b) we perform free page hinting using something that Nitesh proposed. We >> get in QEMU blocks of free pages that we can MADV_FREE. In addition we >> could e.g. clear the dirty bit of these pages in the dirty bitmap, to >> hinder them from getting migrated. Right now the hinting mechanism is >> synchronous (called from arch_free_page()) but we might be able to >> convert it into something asynchronous. >> >> So we might be able to completely get rid of this interface. And looking >> at all the discussions and problems that already happened during the >> development of this series, I think we should rather look into how clean >> free page hinting might solve the same problem. >> >> If it can't be solved using free page hinting, fair enough. >> > > I'm afraid it can't. For example, when we have a guest booted, without > too many memory activities. Assume the guest has 8GB free memory. The > arch_free_page there won't be able to capture the 8GB free pages since > there is no free() called. This results in no free pages reported to host. So, it takes some time from when the guest boots up until the balloon device was initialized and therefore page hinting can start. For that period, you won't get any arch_free_page()/page hinting callbacks, correct. However in the hypervisor, you can theoretically track which pages the guest actually touched ("dirty"), so you already know "which pages were never touched while booting up until virtio-balloon was brought to life". These, you can directly exclude from migration. No interface required. The remaining problem is pages that were touched ("allocated") by the guest during bootup but freed again, before virtio-balloon came up. One would have to measure how many pages these usually are, I would say it would not be that many (because recently freed pages are likely to be used again next for allocation). However, there are some pages not being reported. During the lifetime of the guest, this should not be a problem, eventually one of these pages would get allocated/freed again, so the problem "solves itself over time". You are looking into the special case of migrating the VM just after it has been started. But we have the exact same problem also for ordinary free page hinting, so we should rather solve that problem. It is not migration specific. If we are looking for an alternative to "problem solves itself", something like "if virtio-balloon comes up, it will report all free pages step by step using free page hinting, just like we would have from "arch_free_pages()"". This would be the same interface we are using for free page hinting - and it could even be made configurable in the guest. The current approach we are discussing internally for details about Nitesh's work ("how the magic inside arch_fee_pages() will work efficiently) would allow this as far as I can see just fine. There would be a tiny little window between virtio-balloon comes up and it has reported all free pages step by step, but that can be considered a very special corner case that I would argue is not worth it to be optimized. If I am missing something important here, sorry in advance :) > > Best, > Wei > -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4604-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [66.179.20.138]) by lists.oasis-open.org (Postfix) with ESMTP id 3682C5819233 for ; Fri, 29 Jun 2018 00:46:37 -0700 (PDT) References: <1529928312-30500-1-git-send-email-wei.w.wang@intel.com> <5B35ACD5.4090800@intel.com> From: David Hildenbrand Message-ID: <4840cbb7-dd3f-7540-6a7c-13427de2f0d1@redhat.com> Date: Fri, 29 Jun 2018 09:46:09 +0200 MIME-Version: 1.0 In-Reply-To: <5B35ACD5.4090800@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: [virtio-dev] Re: [PATCH v34 0/4] Virtio-balloon: support free page reporting To: Wei Wang , virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com, mhocko@kernel.org, akpm@linux-foundation.org Cc: torvalds@linux-foundation.org, pbonzini@redhat.com, liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com, peterx@redhat.com, Andrea Arcangeli , Luiz Capitulino List-ID: On 29.06.2018 05:51, Wei Wang wrote: > On 06/27/2018 07:06 PM, David Hildenbrand wrote: >> On 25.06.2018 14:05, Wei Wang wrote: >>> This patch series is separated from the previous "Virtio-balloon >>> Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, >>> implemented by this series enables the virtio-balloon driver to report >>> hints of guest free pages to the host. It can be used to accelerate live >>> migration of VMs. Here is an introduction of this usage: >>> >>> Live migration needs to transfer the VM's memory from the source machine >>> to the destination round by round. For the 1st round, all the VM's memory >>> is transferred. From the 2nd round, only the pieces of memory that were >>> written by the guest (after the 1st round) are transferred. One method >>> that is popularly used by the hypervisor to track which part of memory is >>> written is to write-protect all the guest memory. >>> >>> This feature enables the optimization by skipping the transfer of guest >>> free pages during VM live migration. It is not concerned that the memory >>> pages are used after they are given to the hypervisor as a hint of the >>> free pages, because they will be tracked by the hypervisor and transferred >>> in the subsequent round if they are used and written. >>> >>> * Tests >>> - Test Environment >>> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz >>> Guest: 8G RAM, 4 vCPU >>> Migration setup: migrate_set_speed 100G, migrate_set_downtime 2 second >>> >>> - Test Results >>> - Idle Guest Live Migration Time (results are averaged over 10 runs): >>> - Optimization v.s. Legacy = 284ms vs 1757ms --> ~84% reduction >>> - Guest with Linux Compilation Workload (make bzImage -j4): >>> - Live Migration Time (average) >>> Optimization v.s. Legacy = 1402ms v.s. 2528ms --> ~44% reduction >>> - Linux Compilation Time >>> Optimization v.s. Legacy = 5min6s v.s. 5min12s >>> --> no obvious difference >>> >> Being in version 34 already, this whole thing still looks and feels like >> a big hack to me. It might just be me, but especially if I read about >> assumptions like "QEMU will not hotplug memory during migration". This >> does not feel like a clean solution. >> >> I am still not sure if we really need this interface, especially as real >> free page hinting might be on its way. >> >> a) we perform free page hinting by setting all free pages >> (arch_free_page()) to zero. Migration will detect zero pages and >> minimize #pages to migrate. I don't think this is a good idea but Michel >> suggested to do a performance evaluation and Nitesh is looking into that >> right now. > > The hypervisor doesn't get the zero pages for free. It pays lots of CPU > utilization and memory bandwidth (there are some guys complaining abut > this on the QEMU mailinglist) > In the above results, the legacy part already has the zero page feature > in use. Indeed, I don't consider this attempt not very practical in general, especially as it would rely on KSM right now, which is frowned upon by many people. > >> >> b) we perform free page hinting using something that Nitesh proposed. We >> get in QEMU blocks of free pages that we can MADV_FREE. In addition we >> could e.g. clear the dirty bit of these pages in the dirty bitmap, to >> hinder them from getting migrated. Right now the hinting mechanism is >> synchronous (called from arch_free_page()) but we might be able to >> convert it into something asynchronous. >> >> So we might be able to completely get rid of this interface. And looking >> at all the discussions and problems that already happened during the >> development of this series, I think we should rather look into how clean >> free page hinting might solve the same problem. >> >> If it can't be solved using free page hinting, fair enough. >> > > I'm afraid it can't. For example, when we have a guest booted, without > too many memory activities. Assume the guest has 8GB free memory. The > arch_free_page there won't be able to capture the 8GB free pages since > there is no free() called. This results in no free pages reported to host. So, it takes some time from when the guest boots up until the balloon device was initialized and therefore page hinting can start. For that period, you won't get any arch_free_page()/page hinting callbacks, correct. However in the hypervisor, you can theoretically track which pages the guest actually touched ("dirty"), so you already know "which pages were never touched while booting up until virtio-balloon was brought to life". These, you can directly exclude from migration. No interface required. The remaining problem is pages that were touched ("allocated") by the guest during bootup but freed again, before virtio-balloon came up. One would have to measure how many pages these usually are, I would say it would not be that many (because recently freed pages are likely to be used again next for allocation). However, there are some pages not being reported. During the lifetime of the guest, this should not be a problem, eventually one of these pages would get allocated/freed again, so the problem "solves itself over time". You are looking into the special case of migrating the VM just after it has been started. But we have the exact same problem also for ordinary free page hinting, so we should rather solve that problem. It is not migration specific. If we are looking for an alternative to "problem solves itself", something like "if virtio-balloon comes up, it will report all free pages step by step using free page hinting, just like we would have from "arch_free_pages()"". This would be the same interface we are using for free page hinting - and it could even be made configurable in the guest. The current approach we are discussing internally for details about Nitesh's work ("how the magic inside arch_fee_pages() will work efficiently) would allow this as far as I can see just fine. There would be a tiny little window between virtio-balloon comes up and it has reported all free pages step by step, but that can be considered a very special corner case that I would argue is not worth it to be optimized. If I am missing something important here, sorry in advance :) > > Best, > Wei > -- Thanks, David / dhildenb --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org