Re: [RFC/T/D][PATCH 2/2] Linux/Guest cooperative unmapped page cachecontrol

[Balbir Singh]

* Avi Kivity <avi@xxxxxxxxxx> [2010-06-14 19:34:00]:

> On 06/14/2010 06:55 PM, Dave Hansen wrote:
> >On Mon, 2010-06-14 at 18:44 +0300, Avi Kivity wrote:
> >>On 06/14/2010 06:33 PM, Dave Hansen wrote:
> >>>At the same time, I see what you're trying to do with this.  It really
> >>>can be an alternative to ballooning if we do it right, since ballooning
> >>>would probably evict similar pages.  Although it would only work in idle
> >>>guests, what about a knob that the host can turn to just get the guest
> >>>to start running reclaim?
> >>Isn't the knob in this proposal the balloon?  AFAICT, the idea here is
> >>to change how the guest reacts to being ballooned, but the trigger
> >>itself would not change.
> >I think the patch was made on the following assumptions:
> >1. Guests will keep filling their memory with relatively worthless page
> >    cache that they don't really need.
> >2. When they do this, it hurts the overall system with no real gain for
> >    anyone.
> >
> >In the case of a ballooned guest, they _won't_ keep filling memory.  The
> >balloon will prevent them.  So, I guess I was just going down the path
> >of considering if this would be useful without ballooning in place.  To
> >me, it's really hard to justify _with_ ballooning in place.
> 
> There are two decisions that need to be made:
> 
> - how much memory a guest should be given
> - given some guest memory, what's the best use for it
> 
> The first question can perhaps be answered by looking at guest I/O
> rates and giving more memory to more active guests.  The second
> question is hard, but not any different than running non-virtualized
> - except if we can detect sharing or duplication.  In this case,
> dropping a duplicated page is worthwhile, while dropping a shared
> page provides no benefit.

I think there is another way of looking at it, give some free memory

1. Can the guest run more applications or run faster
2. Can the host potentially get this memory via ballooning or some
other means to start newer guest instances

I think the answer to 1 and 2 is yes.

> 
> How the patch helps answer either question, I'm not sure.  I don't
> think preferential dropping of unmapped page cache is the answer.
>

Preferential dropping as selected by the host, that knows about the
setup and if there is duplication involved. While we use the term
preferential dropping, remember it is still via LRU and we don't
always succeed. It is a best effort (if you can and the unmapped pages
are not highly referenced) scenario.
 
> >>My issue is that changing the type of object being preferentially
> >>reclaimed just changes the type of workload that would prematurely
> >>suffer from reclaim.  In this case, workloads that use a lot of unmapped
> >>pagecache would suffer.
> >>
> >>btw, aren't /proc/sys/vm/swapiness and vfs_cache_pressure similar knobs?
> >Those tell you how to balance going after the different classes of
> >things that we can reclaim.
> >
> >Again, this is useless when ballooning is being used.  But, I'm thinking
> >of a more general mechanism to force the system to both have MemFree
> >_and_ be acting as if it is under memory pressure.
> 
> If there is no memory pressure on the host, there is no reason for
> the guest to pretend it is under pressure.  If there is memory
> pressure on the host, it should share the pain among its guests by
> applying the balloon.  So I don't think voluntarily dropping cache
> is a good direction.
>

There are two situations

1. Voluntarily drop cache, if it was setup to do so (the host knows
that it caches that information anyway)
2. Drop the cache on either a special balloon option, again the host
knows it caches that very same information, so it prefers to free that
up first. 

-- 
	Three Cheers,
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/