Date: Mon, 14 Jun 2010 18:20:10 +0530
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>, kvm <kvm@vger.kernel.org>,
       linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC/T/D][PATCH 2/2] Linux/Guest cooperative unmapped page cache
 control
Message-ID: <20100614125010.GU5191@balbir.in.ibm.com>
Reply-To: balbir@linux.vnet.ibm.com
References: <20100608155140.3749.74418.sendpatchset@L34Z31A.ibm.com>
 <20100608155153.3749.31669.sendpatchset@L34Z31A.ibm.com>
 <4C10B3AF.7020908@redhat.com>
 <20100610142512.GB5191@balbir.in.ibm.com>
 <1276214852.6437.1427.camel@nimitz>
 <20100611045600.GE5191@balbir.in.ibm.com>
 <4C15E3C8.20407@redhat.com>
 <20100614084810.GT5191@balbir.in.ibm.com>
 <4C16233C.1040108@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <4C16233C.1040108@redhat.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3254
Lines: 84

* Avi Kivity <avi@redhat.com> [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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/