On Fri, Jul 20, 2012 at 10:04:34AM +0900, Takuya Yoshikawa wrote: > On Wed, 18 Jul 2012 17:52:46 -0300 > Marcelo Tosatti <mtosa...@redhat.com> wrote: > > > Can't understand, can you please expand more clearly? > > I think mmu pages are not worth freeing under usual memory pressure, > especially when we have EPT/NPT on. > > What's happening: > shrink_slab() vainly calls mmu_shrink() with the default batch size 128, > and mmu_shrink() takes a long time to zap mmu pages far fewer than the > requested number, usually just frees one. Sadly, KVM may recreate the > page soon after that. > > Since we set the seeks 10 times greater than the default, total_scan is > very small and shrink_slab() just wastes time for freeing such small > amount of may-be-reallocated-soon memory: I want it to use time for > scanning other objects instead. > > Actually the total amount of memory used for mmu pages is not huge in > the case of EPT/NPT on: maybe smaller that that of rmap?
rmap size is a function of mmu pages, so mmu_shrink indirectly releases rmap also. > So, it's clear that no one wants mmu pages to be freed as other objects. > Sure, our seeks size prevents shrink_slab() from calling mmu_shrink() > usually. But what if administrators want to drop clean caches on the > host? > > Documentation/sysctl/vm.txt says: > Writing to this will cause the kernel to drop clean caches, dentries and > inodes from memory, causing that memory to become free. > > To free pagecache: > echo 1 > /proc/sys/vm/drop_caches > To free dentries and inodes: > echo 2 > /proc/sys/vm/drop_caches > To free pagecache, dentries and inodes: > echo 3 > /proc/sys/vm/drop_caches > > I don't want mmu pages to be freed in such cases. drop_caches should be used in special occasions. I would not worry about it. > So, how about stopping reporting/returning the total number of used > mmu pages to shrink_slab()? > > If we do so, it will think that there are not enough objects to get > memory back from KVM. No, its important to be able to release memory quickly in low memory conditions. I bet the reasoning behind current seeks value (10*default) is close to arbitrary. mmu_shrink can be smarter, by freeing pages which are less likely to be used. IIRC Avi had some nice ideas for LRU-like schemes (search the archives). You can also consider the fact that freeing a higher level pagetable frees all of its children (that is quite dumb actually, sequential shrink passes should free only pages with no children). > In the case of shadow paging, guests can do bad things to allocate > enormous mmu pages, so we should report such exceeded numbers to > shrink_slab() as freeable objects, not the total. A guest idle for 2 months should not have its mmu pages in memory. > |--- needed ---|--- freeable under memory pressure ---| > > We may be able to use n_max_mmu_pages for this: the shrinker tries > to free mmu pages unless the number reaches the goal. > > Thanks, > Takuya > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
