Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752080AbcCGFfG (ORCPT ); Mon, 7 Mar 2016 00:35:06 -0500 Received: from mga04.intel.com ([192.55.52.120]:45699 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbcCGFe6 convert rfc822-to-8bit (ORCPT ); Mon, 7 Mar 2016 00:34:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,549,1449561600"; d="scan'208";a="918303682" From: "Li, Liang Z" To: "Dr. David Alan Gilbert" , Paolo Bonzini CC: Roman Kagan , "ehabkost@redhat.com" , "kvm@vger.kernel.org" , "mst@redhat.com" , "quintela@redhat.com" , "linux-kernel@vger.kernel.org" , "qemu-devel@nongnu.org" , "linux-mm@kvack.org" , "amit.shah@redhat.com" , "akpm@linux-foundation.org" , "virtualization@lists.linux-foundation.org" , "rth@twiddle.net" Subject: RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Thread-Topic: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Thread-Index: AQHRdTqPjTxTnYWKZEWM4lf/HjT6rZ9HeJiAgAEJK0D//+lWAIAAiTOQ//+bAoCAAMUSUP//n7sAAAUgY4AAh10d8A== Date: Mon, 7 Mar 2016 05:34:54 +0000 Message-ID: References: <1457001868-15949-1-git-send-email-liang.z.li@intel.com> <20160303174615.GF2115@work-vm> <20160304081411.GD9100@rkaganb.sw.ru> <20160304102346.GB2479@rkaganb.sw.ru> <56D9B6C2.3070708@redhat.com> <20160304185120.GB2588@work-vm> In-Reply-To: <20160304185120.GB2588@work-vm> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzIxYmE2M2YtYjhhNS00ZmM1LThjMTgtZTUwYmU3MjY4MjdmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlB2VEtRMW12NFFSWFN5SUYxSjRtU2pTR3pSN0p3bW5mZUptTEljYk50VjQ9In0= 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: 1908 Lines: 46 > > On 04/03/2016 15:26, Li, Liang Z wrote: > > >> > > > >> > The memory usage will keep increasing due to ever growing caches, > > >> > etc, so you'll be left with very little free memory fairly soon. > > >> > > > > I don't think so. > > > > > > > Roman is right. For example, here I am looking at a 64 GB (physical) > > machine which was booted about 30 minutes ago, and which is running > > disk-heavy workloads (installing VMs). > > > > Since I have started writing this email (2 minutes?), the amount of > > free memory has already gone down from 37 GB to 33 GB. I expect that > > by the time I have finished running the workload, in two hours, it > > will not have any free memory. > > But what about a VM sitting idle, or that just has more RAM assigned to it > than is currently using. > I've got a host here that's been up for 46 days and has been doing some > heavy VM debugging a few days ago, but today: > > # free -m > total used free shared buff/cache available > Mem: 96536 1146 44834 184 50555 94735 > > I very rarely use all it's RAM, so it's got a big chunk of free RAM, and yes it's > got a big chunk of cache as well. > > Dave > > > > > Paolo I begin to realize Roman's opinions. The PV solution can't handle the cache memory while inflating balloon could. Inflating balloon so as to skipping the cache memory is no good for guest's performance. How much of the free memory in the guest depends on the workload in the VM and the time VM has already run before live migration. Even the memory usage will keep increasing due to ever growing caches, but we don't know when the live migration will happen, assuming there are no or very little free pages in the guest is not quite right. The advantage of the pv solution is the smaller performance impact, comparing with inflating the balloon. Liang