From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] shrinker support for the mmu cache Date: Mon, 17 Mar 2008 16:41:18 +0200 Message-ID: <47DE830E.80404@qumranet.com> References: <1205345621.16712.4.camel@localhost.localdomain> <20080312225927.GA30597@dmt> <47DD046B.70404@qumranet.com> <20080317135332.GA4854@dmt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Marcelo Tosatti Return-path: In-Reply-To: <20080317135332.GA4854@dmt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Marcelo Tosatti wrote: >> >> While aging is not too hard to do, I don't think it would add much in >> practice; we rarely observe mmu shadow pages being recycled due to >> memory pressure. So this is mostly helpful for preventing a VM from >> pinning memory when under severe memory pressure, where we don't expect >> good performance anyway. >> > > Issue is that the shrinker callback will not be called only under > severe memory pressure, but for normal system pressure too. > > How much shrinkage goes on under normal pressure? Rebuilding a single shadow page costs a maximum of 512 faults (so about 1 msec). If the shrinker evicts one entry per second, this is a performance hiy of 0.1%. Perhaps if we set the cost high enough, the normal eviction rate will be low enough. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/