[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux
- To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
- From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
- Date: Thu, 09 Jul 2009 16:41:40 -0500
- Cc: npiggin@xxxxxxx, akpm@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dave.mccracken@xxxxxxxxxx, linux-mm@xxxxxxxxx, chris.mason@xxxxxxxxxx, sunil.mushran@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, jeremy@xxxxxxxx, Schwidefsky <schwidefsky@xxxxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, alan@xxxxxxxxxxxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 09 Jul 2009 14:43:52 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
Dan Magenheimer wrote:
CMM2's focus is on increasing the number of VM's that
can run on top of the hypervisor. To do this, it
depends on hints provided by Linux to surreptitiously
steal memory away from Linux. The stolen memory still
"belongs" to Linux and if Linux goes to use it but the
hypervisor has already given it to another Linux, the
hypervisor must jump through hoops to give it back.
It depends on how you define "jump through hoops".
If it guesses wrong and overcommits too aggressively,
the hypervisor must swap some memory to a "hypervisor
swap disk" (which btw has some policy challenges).
IMHO this is more of a "mainframe" model.
No, not at all. A guest marks a page as being "volatile", which tells
the hypervisor it never needs to swap that page. It can discard it
whenever it likes.
If the guest later tries to access that page, it will get a special
"discard fault". For a lot of types of memory, the discard fault
handler can then restore that page transparently to the code that
generated the discard fault.
AFAICT, ephemeral tmem has the exact same characteristics as volatile
CMM2 pages. The difference is that tmem introduces an API to explicitly
manage this memory behind a copy interface whereas CMM2 uses hinting and
a special fault handler to allow any piece of memory to be marked in
In other words, CMM2, despite its name, is more of a
"subservient" memory management system (Linux is
subservient to the hypervisor) and tmem is more
collaborative (Linux and the hypervisor share the
responsibilities and the benefits/costs).
I don't really agree with your analysis of CMM2. We can map CMM2
operations directly to ephemeral tmem interfaces so tmem is a subset of
What's appealing to me about CMM2 is that it doesn't change the guest
semantically but rather just gives the VMM more information about how
the VMM is using it's memory. This suggests that it allows greater
flexibility in the long term to the VMM and more importantly, provides
an easier implementation across a wide range of guests.
Xen-devel mailing list