On Thu, Jan 23, 2020 at 09:20:15AM -0800, Dave Hansen wrote: > On 1/23/20 8:26 AM, Alexander Duyck wrote: > >> The big piece I'm missing is the page cache. Linux will by default try > >> to keep the free list as small as it can in favor of page cache, so most > >> of the benefit of this patch set will be void in real world scenarios. > > Agreed. This is a the next piece of this I plan to work on once this is > > accepted. For now the quick and dirty approach is to essentially make use > > of the /proc/sys/vm/drop_caches interface in the guest by either putting > > it in a cronjob somewhere or to have it after memory intensive workloads. > > There was an implementation in "Clear Linux" that used this sysctl: > > > https://github.com/Conan-Kudo/omv-kernel-rc/blob/master/0154-sysctl-vm-Fine-grained-cache-shrinking.patch > > (I can't find it in the Clear repos at the moment, must not be used > currently). But the idea was to have a little daemon in the host that > periodically applied some artificial pressure with this sysctl. This > sysctl is a smaller hammer than /proc/sys/vm/drop_caches and lets you > drop small amounts of cache. > > The right way to do it is probably to do real, generic reclaim instead > of drop_caches. This sounds like Transcendent Memory (https://www.linux-kvm.org/images/d/d7/TmemNotVirt-Linuxcon2011-Final.pdf) which has (which is in the Linux kernel) a driver to push on the swapper and everything else to evict pages to the hypervisor. Look at cleancache and frontswap and xen-selfballoon.c (was removed by by 814bbf49dcd0ad642e7ceb8991e57555c5472cce) Avi Kivity pointed out one big issue with all of this - customers have to be nicely behaved - which they don't seem to be. But I would recommend you look at cleancache for the page cache. > > This isn't conceptually *that* far away from the "proactive reclaim" > that other folks have proposed: > > https://lwn.net/Articles/787611/
