From: Rik van Riel <riel@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
akpm@osdl.org, frankeh@watson.ibm.com, hugh@veritas.com
Subject: Re: [patch 0/6] Guest page hinting version 7.
Date: Thu, 02 Apr 2009 16:05:22 -0400 [thread overview]
Message-ID: <49D51A82.8090908@redhat.com> (raw)
In-Reply-To: <200904030622.30935.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
> On Friday 03 April 2009 06:06:31 Rik van Riel wrote:
>
>> Ballooning has a simpler mechanism, but relies on an
>> as-of-yet undiscovered policy.
>>
>> Having experienced a zillion VM corner cases over the
>> last decade and a bit, I think I prefer a complex mechanism
>> over complex (or worse, unknown!) policy any day.
>>
>
> I disagree with it being so clear cut. Volatile pagecache policy is completely
> out of the control of the Linux VM. Wheras ballooning does have to make some
> tradeoff between guests, but the actual reclaim will be driven by the guests.
> Neither way is perfect, but it's not like the hypervisor reclaim is foolproof
> against making a bad tradeoff between guests.
>
I guess we could try to figure out a simple and robust policy
for ballooning. If we can come up with a policy which nobody
can shoot holes in by just discussing it, it may be worth
implementing and benchmarking.
Maybe something based on the host passing memory pressure
on to the guests, and the guests having their own memory
pressure push back to the host.
I'l start by telling you the best auto-ballooning policy idea
I have come up with so far, and the (major?) hole in it.
Basically, the host needs the memory pressure notification,
where the VM will notify the guests when memory is running
low (and something could soon be swapped). At that point,
each guest which receives the signal will try to free some
memory and return it to the host.
Each guest can have the reverse in its own pageout code.
Once memory pressure grows to a certain point (eg. when
the guest is about to swap something out), it could reclaim
a few pages from the host.
If all the guests behave themselves, this could work.
However, even with just reasonably behaving guests,
differences between the VMs in each guest could lead
to unbalanced reclaiming, penalizing better behaving
guests.
If one guest is behaving badly, it could really impact
the other guests.
Can you think of improvements to this idea?
Can you think of another balloon policy that does
not have nasty corner cases?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-04-02 20:05 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 15:09 [patch 0/6] Guest page hinting version 7 Martin Schwidefsky
2009-03-27 15:09 ` [patch 1/6] Guest page hinting: core + volatile page cache Martin Schwidefsky
2009-03-27 22:57 ` Rik van Riel
2009-03-29 13:56 ` Martin Schwidefsky
2009-03-29 14:35 ` Rik van Riel
2009-03-27 15:09 ` [patch 2/6] Guest page hinting: volatile swap cache Martin Schwidefsky
2009-04-01 2:10 ` Rik van Riel
2009-04-01 8:13 ` Martin Schwidefsky
2009-03-27 15:09 ` [patch 3/6] Guest page hinting: mlocked pages Martin Schwidefsky
2009-04-01 2:52 ` Rik van Riel
2009-04-01 8:13 ` Martin Schwidefsky
2009-03-27 15:09 ` [patch 4/6] Guest page hinting: writable page table entries Martin Schwidefsky
2009-04-01 13:25 ` Rik van Riel
2009-04-01 14:36 ` Martin Schwidefsky
2009-04-01 14:45 ` Rik van Riel
2009-03-27 15:09 ` [patch 5/6] Guest page hinting: minor fault optimization Martin Schwidefsky
2009-04-01 15:33 ` Rik van Riel
2009-03-27 15:09 ` [patch 6/6] Guest page hinting: s390 support Martin Schwidefsky
2009-04-01 16:18 ` Rik van Riel
2009-03-27 23:03 ` [patch 0/6] Guest page hinting version 7 Dave Hansen
2009-03-28 0:06 ` Rik van Riel
2009-03-29 14:20 ` Martin Schwidefsky
2009-03-29 14:38 ` Rik van Riel
2009-03-29 14:12 ` Martin Schwidefsky
2009-03-30 15:54 ` Dave Hansen
2009-03-30 16:34 ` Martin Schwidefsky
2009-03-30 18:37 ` Jeremy Fitzhardinge
2009-03-30 18:42 ` Rik van Riel
2009-03-30 18:59 ` Jeremy Fitzhardinge
2009-03-30 20:02 ` Rik van Riel
2009-03-30 20:35 ` Jeremy Fitzhardinge
2009-03-30 21:38 ` Dor Laor
2009-03-30 22:16 ` Izik Eidus
2009-03-28 6:35 ` Rusty Russell
2009-03-29 14:23 ` Martin Schwidefsky
2009-04-02 11:32 ` Nick Piggin
2009-04-02 15:52 ` Martin Schwidefsky
2009-04-02 16:18 ` Jeremy Fitzhardinge
2009-04-02 16:23 ` Nick Piggin
2009-04-02 19:06 ` Rik van Riel
2009-04-02 19:22 ` Nick Piggin
2009-04-02 20:05 ` Rik van Riel [this message]
2009-04-03 0:50 ` Jeremy Fitzhardinge
2009-04-02 19:58 ` Jeremy Fitzhardinge
2009-04-02 20:14 ` Rik van Riel
2009-04-02 20:34 ` Jeremy Fitzhardinge
2009-04-03 8:49 ` Martin Schwidefsky
2009-04-03 18:19 ` Jeremy Fitzhardinge
2009-04-06 7:21 ` Martin Schwidefsky
2009-04-06 7:32 ` Nick Piggin
2009-04-06 19:23 ` Jeremy Fitzhardinge
2009-04-02 19:27 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D51A82.8090908@redhat.com \
--to=riel@redhat.com \
--cc=akpm@osdl.org \
--cc=frankeh@watson.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rusty@rustcorp.com.au \
--cc=schwidefsky@de.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=virtualization@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).