From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiucG-0004ZI-6J for qemu-devel@nongnu.org; Wed, 23 Mar 2016 22:03:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiucC-00054j-Qi for qemu-devel@nongnu.org; Wed, 23 Mar 2016 22:03:16 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:24281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiucB-00054P-Vq for qemu-devel@nongnu.org; Wed, 23 Mar 2016 22:03:12 -0400 Date: Thu, 24 Mar 2016 09:56:05 +0800 From: Wei Yang Message-ID: <20160324015605.GC14956@linux-gk3p> References: <1458632629-4649-1-git-send-email-liang.z.li@intel.com> <20160323013715.GB13750@linux-gk3p> <20160323094643.GA18660@linux-gk3p> <20160324005256.GA14956@linux-gk3p> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages Reply-To: Wei Yang List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Li, Liang Z" Cc: "rkagan@virtuozzo.com" , "linux-kernel@vger.kenel.org" , "ehabkost@redhat.com" , "kvm@vger.kernel.org" , "mst@redhat.com" , "simhan@hpe.com" , "quintela@redhat.com" , "qemu-devel@nongnu.org" , "dgilbert@redhat.com" , "jitendra.kolhe@hpe.com" , "mohan_parthasarathy@hpe.com" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , Wei Yang , "rth@twiddle.net" On Thu, Mar 24, 2016 at 01:32:25AM +0000, Li, Liang Z wrote: >> >> >> > >> >> >> >6. Handling page cache in the guest The memory used for page >> >> >> >cache in the guest will change depends on the workload, if guest >> >> >> >run some block IO intensive work load, there will >> >> >> >> >> >> Would this improvement benefit a lot when guest only has little free >> page? >> >> > >> >> >Yes, the improvement is very obvious. >> >> > >> >> >> >> Good to know this. >> >> >> >> >> In your Performance data Case 2, I think it mimic this kind of case. >> >> >> While the memory consuming task is stopped before migration. If it >> >> >> continues, would we still perform better than before? >> >> > >> >> >Actually, my RFC patch didn't consider the page cache, Roman raised >> >> >this >> >> issue. >> >> >so I add this part in this doc. >> >> > >> >> >Case 2 didn't mimic this kind of scenario, the work load is an >> >> >memory consuming work load, not an block IO intensive work load, so >> >> >there are not many page cache in this case. >> >> > >> >> >If the work load in case 2 continues, as long as it not write all >> >> >the memory it allocates, we still can get benefits. >> >> > >> >> >> >> Sounds I have little knowledge on page cache, and its relationship >> >> between free page and I/O intensive work. >> >> >> >> Here is some personal understanding, I would appreciate if you could >> >> correct me. >> >> >> >> +---------+ >> >> |PageCache| >> >> +---------+ >> >> +---------+---------+---------+---------+ >> >> |Page |Page |Free Page|Page | >> >> +---------+---------+---------+---------+ >> >> >> >> Free Page is a page in the free_list, PageCache is some page cached >> >> in CPU's cache line? >> > >> >No, page cache is quite different with CPU cache line. >> >" In computing, a page cache, sometimes also called disk cache,[2] is a >> >transparent cache for the pages originating from a secondary storage >> device such as a hard disk drive (HDD). >> > The operating system keeps a page cache in otherwise unused portions >> >of the main memory (RAM), resulting in quicker access to the contents >> >of cached pages and overall performance improvements " >> >you can refer to https://en.wikipedia.org/wiki/Page_cache >> >for more details. >> > >> >> My poor knowledge~ Should google it before I imagine the meaning of the >> terminology. >> >> If my understanding is correct, the Page Cache is counted as Free Page, while >> actually we should migrate them instead of filter them. > >No, the Page Cache is not counted as Free Page ... OK, I misunderstand the concept in wiki. The Page Cache is a trade off between Free Page percentage and the I/O performance in guest. > >Liang -- Richard Yang\nHelp you, Help me