Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752359AbcCIGSP (ORCPT ); Wed, 9 Mar 2016 01:18:15 -0500 Received: from mga09.intel.com ([134.134.136.24]:50753 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751085AbcCIGSE convert rfc822-to-8bit (ORCPT ); Wed, 9 Mar 2016 01:18:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,310,1455004800"; d="scan'208";a="919935279" From: "Li, Liang Z" To: Paolo Bonzini , Roman Kagan CC: "Dr. David Alan Gilbert" , "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//n7sAAPWMA5A= Date: Wed, 9 Mar 2016 06:18:00 +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> In-Reply-To: <56D9B6C2.3070708@redhat.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjVlYzcwOGMtMjNjYy00N2M5LWJjNTktMGFjOTJjYTNjNjhjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFGNjJxOVwvcE5uNThWY201RkZzUml1Uk5MOUM0SHhZVEN0UGZpTzk1REpJPSJ9 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: 1345 Lines: 29 > 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. > > Paolo I have a VM which has 2GB of RAM, when the guest booted, there were about 1.4GB of free pages. Then I tried to download a large file from the internet with the browser, after the downloading finished, there were only 72MB of free pages left, as Roman pointed out, there were quite a lot of Cached memory. Then I tried to compile the QEMU, after the compiling finished, there were about 1.3G free pages. So even the cache will increase to a large amount, it will be freed if there are some other specific workloads. The cache memory is a big issue that should be taken into consideration. How about reclaim some cache before getting the free pages information? Liang