[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging

  • To: "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Tue, 28 Feb 2012 07:25:49 -0800
  • Cc: Olaf Hering <olaf@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>
  • Delivery-date: Tue, 28 Feb 2012 15:26:16 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=EIErPKxZ6GAkgwIXMPMBLoiVnISrt7tIdJM8QFqY40ZK Yks//ISMPzjLTfiA2+lkzQ5+2wGlDqryNzg396FCBmQqNi2w/OMaDdsi2JUqhzrX /WmrFRcRVDt5fObYTh22w1/kPWkcCEih7vAzidSjVwLtlINuYzg7Tkh/9psQv/o=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

> On Mon, Feb 27, 2012 at 2:45 PM, Andres Lagar-Cavilla
> <andres@xxxxxxxxxxxxxxxx> wrote:
>>> On Fri, 2012-02-24 at 17:12 +0000, Andres Lagar-Cavilla wrote:
>>>> Sharing + balloon is mostly a bad idea. It's not forbidden or broken
>>>> from the hypervisor angle, but it's a lose-lose game. Ballooning a
>>>> shared page gains you nothing. The ballooner can't know what is shared
>>>> and what isn't, in order to make an educated decision. And the sharer
>>>> can't foresee what the balloon will victimize.
>>> Doesn't ballooning generally evict unused pages, because it allocates
>>> new _free_ pages, even if they were shared is there any benefit to
>>> doing
>>> so?
>> Certainly the balloon will pick free pages. The sharing daemon should
>> not
>> have shared those, but it's not unlikely that it will have.
>> It's a classic semantic gap problem, and we were discussing this in the
>> context of paging ("the pager should not have paged out page table
>> pages")
>> Beyond free pages, a prime target for sharing are read-only disk buffers
>> in the page cache. Those are victim #2 for the balloon.
> Not exactly -- victim #2 would be read-only disk buffers *which have
> not been read recently*.

Everything's been read recently in Windows. Seriously ;)

> Buffers which are in active use will not be
> evicted.  So although evicting these pages from the guests' cache
> doesn't buy the system any more memory, it doesn't have a major impact
> on the guest either.

That's debatable. Maybe guests shouldn't have a page cache then. Or a
really small one.

I'm not saying you're wrong, I'm saying that the answer is, as with many
things, "it depends"

> In any case, if the guest experiences its own internal memory
> pressure, these pages will be the first to go anyway.  After that, it
> will go for trying to evict infrequently-used read-write pages --
> which, if the pager is active, will already have been paged out to
> disk; thus we'll end up with the double-paging problem.  This will
> have a much larger impact on performance than uselessly evicting
> little-used read-only pages.
> So I think that even though sharing+balloon will lead to some
> occasional sub-optimal behavior, it's still a lot better than
> sharing+paging and no ballooning.  Remember that ballooning was a
> technique introduced in the paper by VMWare that talked about page
> sharing -- they obviously thought sharing+ballooning was better than
> sharing+paging.

Ties in with Dan's thread. Depends on how much effort you spend choosing
sharing and paging candidates, and how hard you inflate the balloon. I'm
not in favor of any such overarching statement (even though I made one


>  -George

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.