[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [RFC/T/D][PATCH 2/2] Linux/Guest cooperative unmapped page cache
From:       Avi Kivity <avi () redhat ! com>
Date:       2010-06-15 7:07:48
Message-ID: 4C1726C4.8050300 () redhat ! com
[Download RAW message or body]

On 06/14/2010 08:58 PM, Dave Hansen wrote:
> On Mon, 2010-06-14 at 19:34 +0300, Avi Kivity wrote:
>    
>>> 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.
>>      
> I can think of quite a few places where this would be beneficial.
>
> Ballooning is dangerous.  I've OOMed quite a few guests by
> over-ballooning them.  Anything that's voluntary like this is safer than
> things imposed by the host, although you do trade of effectiveness.
>    

That's a bug that needs to be fixed.  Eventually the host will come 
under pressure and will balloon the guest.  If that kills the guest, the 
ballooning is not effective as a host memory management technique.

Trying to defer ballooning by voluntarily dropping cache is simply 
trying to defer being bitten by the bug.

> If all the guests do this, then it leaves that much more free memory on
> the host, which can be used flexibly for extra host page cache, new
> guests, etc...

If the host detects lots of pagecache misses it can balloon guests 
down.  If pagecache is quiet, why change anything?

If the host wants to start new guests, it can balloon guests down.  If 
no new guests are wanted, why change anything?

etc...

> A system in this state where everyone is proactively
> keeping their footprints down is more likely to be able to handle load
> spikes.

That is true.  But from the guest's point of view, voluntarily giving up 
memory means dropping the guest's cushion vs load spikes.

> Reclaim is an expensive, costly activity, and this ensures that
> we don't have to do that when we're busy doing other things like
> handling load spikes.

The guest doesn't want to reclaim memory from the host when it's under a 
load spike either.

> This was one of the concepts behind CMM2: reduce
> the overhead during peak periods.
>    

Ah, but CMM2 actually reduced work being done by sharing information 
between guest and host.

> It's also handy for planning.  Guests exhibiting this behavior will
> _act_ as if they're under pressure.  That's a good thing to approximate
> how a guest will act when it _is_ under pressure.
>    

If a guest acts as if it is under pressure, then it will be slower and 
consume more cpu.  Bad for both guest and host.

>> 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.
>>      
> I think we're trying to consider things slightly outside of ballooning
> at this point.  If ballooning was the end-all solution, I'm fairly sure
> Balbir wouldn't be looking at this stuff.  Just trying to keep options
> open. :)
>    

I see this as an extension to ballooning - perhaps I'm missing the big 
picture.  I would dearly love to have CMM2 where decisions are made on a 
per-page basis instead of using heuristics.

-- 
error compiling committee.c: too many arguments to function

--
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/
[prev in list] [next in list] [prev in thread] [next in thread]