From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Rik van Riel <riel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Cc: linux-kernel@vger.kernel.org, npiggin@suse.de, akpm@osdl.org,
jeremy@goop.org, xen-devel@lists.xensource.com,
tmem-devel@oss.oracle.com, alan@lxorguk.ukuu.org.uk,
linux-mm@kvack.org, kurt.hackel@oracle.com,
Rusty Russell <rusty@rustcorp.com.au>,
dave.mccracken@oracle.com, Marcelo Tosatti <mtosatti@redhat.com>,
sunil.mushran@oracle.com, Avi Kivity <avi@redhat.com>,
Schwidefsky <schwidefsky@de.ibm.com>,
chris.mason@oracle.com, Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: RE: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux
Date: Thu, 9 Jul 2009 14:09:30 -0700 (PDT) [thread overview]
Message-ID: <c0e57d57-3f36-4405-b3f1-1a8c48089394@default> (raw)
In-Reply-To: <4A5545CC.9030909@redhat.com>
> > I have trouble mapping this to a VMM capable of overcommit
> without just
> > coming back to CMM2.
>
> Same for me. CMM2 has a more complex mechanism, but way
> easier policy than anything else out there.
Although tmem and CMS have similar conceptual objectives,
let me try to describe what I see as a fundamental
difference in approach.
The primary objective of both is to utilize RAM more
efficiently. Both are ideally complemented with some
longer term "memory shaping" mechanism such as automatic
ballooning or hotplug.
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.
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.
Tmem's focus is on helping Linux to aggressively manage
the amount of memory it uses (and thus reduce the amount
of memory it would get "billed" for using). To do this, it
provides two "safety valve" services, one to reduce the
cost of "refaults" (Rik's term) and the other to reduce
the cost of swapping. Both services are almost
always available, but if the memory of the physical
machine get overcommitted, the most aggressive Linux
guests must fall back to using their disks (because the
hypervisor does not have a "hypervisor swap disk"). But
when physical memory is undercommitted, it is still being
used usefully without compromising "memory liquidity".
(I like this term Jeremy!) IMHO this is more of a "cloud"
model.
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'm not saying either one is bad or good -- and I'm sure
each can be adapted to approximately deliver the value
of the other -- they are just approaching the same problem
from different perspectives.
--
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-07-09 20:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 16:17 Dan Magenheimer
2009-07-07 17:28 ` Rik van Riel
2009-07-07 19:53 ` Dan Magenheimer
2009-07-08 22:56 ` Anthony Liguori
2009-07-08 23:31 ` [Xen-devel] " Dan Magenheimer
2009-07-08 23:57 ` Anthony Liguori
2009-07-09 0:17 ` Jeremy Fitzhardinge
2009-07-09 0:27 ` Anthony Liguori
2009-07-09 1:20 ` Rik van Riel
2009-07-09 21:09 ` Dan Magenheimer [this message]
2009-07-09 21:27 ` Rik van Riel
2009-07-09 21:48 ` Dan Magenheimer
2009-07-09 21:41 ` Anthony Liguori
2009-07-09 22:34 ` Dan Magenheimer
2009-07-09 22:45 ` Rik van Riel
2009-07-09 23:33 ` Anthony Liguori
2009-07-10 15:23 ` Dan Magenheimer
2009-07-12 9:20 ` Avi Kivity
2009-07-12 16:28 ` Dan Magenheimer
2009-07-12 17:27 ` Avi Kivity
2009-07-12 20:59 ` Dan Magenheimer
2009-07-12 13:28 ` Anthony Liguori
2009-07-12 16:20 ` Dan Magenheimer
2009-07-12 17:16 ` Avi Kivity
2009-07-12 19:34 ` Anthony Liguori
2009-07-13 20:17 ` Chris Mason
2009-07-13 20:38 ` Anthony Liguori
2009-07-13 20:38 ` Anthony Liguori
2009-07-13 21:01 ` Chris Mason
2009-07-13 21:17 ` Anthony Liguori
2009-07-26 15:00 ` Avi Kivity
2009-07-12 20:39 ` [Xen-devel] " Dan Magenheimer
2009-07-12 20:43 ` Avi Kivity
2009-07-12 21:08 ` Dan Magenheimer
2009-07-13 11:33 ` Avi Kivity
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=c0e57d57-3f36-4405-b3f1-1a8c48089394@default \
--to=dan.magenheimer@oracle.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=chris.mason@oracle.com \
--cc=dave.mccracken@oracle.com \
--cc=jeremy@goop.org \
--cc=kurt.hackel@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtosatti@redhat.com \
--cc=npiggin@suse.de \
--cc=riel@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=schwidefsky@de.ibm.com \
--cc=sunil.mushran@oracle.com \
--cc=tmem-devel@oss.oracle.com \
--cc=xen-devel@lists.xensource.com \
/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