* Avi Kivity <avi@xxxxxxxxxx> [2010-06-14 15:40:28]: > On 06/14/2010 11:48 AM, Balbir Singh wrote: > >>> > >>>In this case the order is as follows > >>> > >>>1. First we pick free pages if any > >>>2. If we don't have free pages, we go after unmapped page cache and > >>>slab cache > >>>3. If that fails as well, we go after regularly memory > >>> > >>>In the scenario that you describe, we'll not be able to easily free up > >>>the frequently referenced page from /etc/*. The code will move on to > >>>step 3 and do its regular reclaim. > >>Still it seems to me you are subverting the normal order of reclaim. > >>I don't see why an unmapped page cache or slab cache item should be > >>evicted before a mapped page. Certainly the cost of rebuilding a > >>dentry compared to the gain from evicting it, is much higher than > >>that of reestablishing a mapped page. > >> > >Subverting to aviod memory duplication, the word subverting is > >overloaded, > > Right, should have used a different one. > > >let me try to reason a bit. First let me explain the > >problem > > > >Memory is a precious resource in a consolidated environment. > >We don't want to waste memory via page cache duplication > >(cache=writethrough and cache=writeback mode). > > > >Now here is what we are trying to do > > > >1. A slab page will not be freed until the entire page is free (all > >slabs have been kfree'd so to speak). Normal reclaim will definitely > >free this page, but a lot of it depends on how frequently we are > >scanning the LRU list and when this page got added. > >2. In the case of page cache (specifically unmapped page cache), there > >is duplication already, so why not go after unmapped page caches when > >the system is under memory pressure? > > > >In the case of 1, we don't force a dentry to be freed, but rather a > >freed page in the slab cache to be reclaimed ahead of forcing reclaim > >of mapped pages. > > Sounds like this should be done unconditionally, then. An empty > slab page is worth less than an unmapped pagecache page at all > times, no? > In a consolidated environment, even at the cost of some CPU to run shrinkers, I think potentially yes. > >Does the problem statement make sense? If so, do you agree with 1 and > >2? Is there major concern about subverting regular reclaim? Does > >subverting it make sense in the duplicated scenario? > > > > In the case of 2, how do you know there is duplication? You know > the guest caches the page, but you have no information about the > host. Since the page is cached in the guest, the host doesn't see > it referenced, and is likely to drop it. True, that is why the first patch is controlled via a boot parameter that the host can pass. For the second patch, I think we'll need something like a balloon <size> <cache?> with the cache argument being optional. > > If there is no duplication, then you may have dropped a > recently-used page and will likely cause a major fault soon. > Yes, agreed. -- Three Cheers, Balbir -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
