Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 23 Jan 2020 14:23:59 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Alexander Duyck <alexander.h.duyck@linux.intel.com>,
        Alexander Graf <graf@amazon.com>,
        Alexander Duyck <alexander.duyck@gmail.com>,
        kvm@vger.kernel.org, mst@redhat.com, linux-kernel@vger.kernel.org,
        willy@infradead.org, mhocko@kernel.org, linux-mm@kvack.org,
        akpm@linux-foundation.org, mgorman@techsingularity.net,
        vbabka@suse.cz, "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
        yang.zhang.wz@gmail.com, nitesh@redhat.com, david@redhat.com,
        pagupta@redhat.com, riel@surriel.com, lcapitulino@redhat.com,
        wei.w.wang@intel.com, aarcange@redhat.com, pbonzini@redhat.com,
        dan.j.williams@intel.com, osalvador@suse.de,
        "Paterson-Jones, Roland" <rolandp@amazon.com>, hannes@cmpxchg.org,
        hare@suse.com, "Boeuf, Sebastien" <sebastien.boeuf@intel.com>
Subject: Re: [PATCH v16.1 0/9] mm / virtio: Provide support for free page
 reporting
Message-ID: <20200123192359.GB11346@char.us.oracle.com>
References: <20200122173040.6142.39116.stgit@localhost.localdomain>
 <914aa4c3-c814-45e0-830b-02796b00b762@amazon.com>
 <af0b12780092e0007ec9e6dbfc92bc15b604b8f4.camel@linux.intel.com>
 <21444cdc-76f9-1b06-093e-950cbeb4aa1f@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21444cdc-76f9-1b06-093e-950cbeb4aa1f@intel.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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/