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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
