From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] shrinker support for the mmu cache Date: Tue, 18 Mar 2008 08:29:39 +0200 Message-ID: <47DF6153.8090708@qumranet.com> References: <1205345621.16712.4.camel@localhost.localdomain> <20080312225927.GA30597@dmt> <47DD046B.70404@qumranet.com> <20080317135332.GA4854@dmt> <47DE830E.80404@qumranet.com> <20080317213352.GA8552@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: <20080317213352.GA8552@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: > On Mon, Mar 17, 2008 at 04:41:18PM +0200, Avi Kivity wrote: > >> 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? >> > > It depends on the number of LRU pages scanned and the size of the cache. > > Roughly the number of LRU pages scanned divided by shrinker->seeks, > relative to cache size (mm/vmscan.c shrink_slab). > > Since the maximum cache size is a small fraction of memory size, I think we should be okay here. >> 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. >> > > I think its pretty easy to check for the referenced bit on pages to > avoid recently used ones from being zapped. > Not so easy: - the pages don't have an accessed bit, the parent ptes do, so we need to scan the parent ptes list - pages start out referenced, so we need to age them in two stages: first clear the accessed bits (and move them back to the tail of the queue); if we find a page on the head with all accessed bits clear, we can throw it away. - root pages don't have parent ptes, so we need to track access to them manually - if the accessed bit clearing rate is too high, it loses its meaning Nothing horribly hard, but not trivial either. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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/