This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Wed, 08 Jul 2009 19:27:43 -0500
Cc: npiggin@xxxxxxx, akpm@xxxxxxxx, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, alan@xxxxxxxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dave.mccracken@xxxxxxxxxx, linux-mm@xxxxxxxxx, sunil.mushran@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Schwidefsky <schwidefsky@xxxxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, chris.mason@xxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 08 Jul 2009 17:28:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A553707.5060107@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <ac5dec0d-e593-4a82-8c9d-8aa374e8c6ed@default> <4A553272.5050909@xxxxxxxxxxxxx> <4A553707.5060107@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090320)
Jeremy Fitzhardinge wrote:
On 07/08/09 16:57, Anthony Liguori wrote:
Why does tmem require a special store?

A VMM can trap write operations pages can be stored on disk
transparently by the VMM if necessary.  I guess that's the bit I'm

tmem doesn't store anything to disk.  It's more about making sure that
free host memory can be quickly and efficiently be handed out to guests
as they need it; to increase "memory liquidity" as it were.  Guests need
to explicitly ask to use tmem, rather than having the host/hypervisor
try to intuit what to do based on access patterns and hints; typically
they'll use tmem as the first line storage for memory which they were
about to swap out anyway.

If the primary use of tmem is to avoid swapping when measure pressure would have forced it, how is this different using ballooning along with a shrinker callback?

With virtio-balloon, a guest can touch any of the memory it's ballooned to immediately reclaim that memory. I think the main difference with tmem is that you can also mark a page as being volatile. The hypervisor can then reclaim that page without swapping it (it can always reclaim memory and swap it) and generate a special fault to the guest if it attempts to access it.

You can fail to put with tmem, right? You can also fail to get? In both cases though, these failures can be handled because Linux is able to recreate the page on it's on (by doing disk IO). So why not just generate a special fault instead of having to introduce special accessors?


Anthony Liguori

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>