Prev: Cleanup: use for_each_online_cpu in vmstat
Next: blkiocg_update_io_add_stats(): INFO: trying to register non-static key
From: Dave Hansen on 14 Jun 2010 12:00
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.

> 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.

Balbir, can you elaborate a bit on why you would need these patches on a
guest that is being ballooned?

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Hansen on 14 Jun 2010 13:10
On Mon, 2010-06-14 at 22:28 +0530, Balbir Singh wrote:
> If you've got duplicate pages and you know
> that they are duplicated and can be retrieved at a lower cost, why
> wouldn't we go after them first?

I agree with this in theory. But, the guest lacks the information about
what is truly duplicated and what the costs are for itself and/or the
host to recreate it. "Unmapped page cache" may be the best proxy that
we have at the moment for "easy to recreate", but I think it's still too
poor a match to make these patches useful.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Hansen on 14 Jun 2010 14:00
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.

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... A system in this state where everyone is proactively
keeping their footprints down is more likely to be able to handle 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. This was one of the concepts behind CMM2: reduce
the overhead during peak periods.

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 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. :)

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Hansen on 15 Jun 2010 10:50
On Tue, 2010-06-15 at 10:07 +0300, Avi Kivity wrote:
> 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.

I'm not convinced that it's just a bug that can be fixed. Consider a
case where a host sees a guest with 100MB of free memory at the exact
moment that a database app sees that memory. The host tries to balloon
that memory away at the same time that the app goes and allocates it.
That can certainly lead to an OOM very quickly, even for very small
amounts of memory (much less than 100MB). Where's the bug?

I think the issues are really fundamental to ballooning.

> > 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?

Page cache misses alone are not really sufficient. This is the classic
problem where we try to differentiate streaming I/O (which we can't
effectively cache) from I/O which can be effectively cached.

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

We're talking about an environment which we're always trying to
optimize. Imagine that we're always trying to consolidate guests on to
smaller numbers of hosts. We're effectively in a state where we
_always_ want new guests.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: Cleanup: use for_each_online_cpu in vmstat
Next: blkiocg_update_io_add_stats(): INFO: trying to register non-static key