xen-devel
[Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") f
To: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux |
From: |
Avi Kivity <avi@xxxxxxxxxx> |
Date: |
Sun, 12 Jul 2009 20:16:01 +0300 |
Cc: |
npiggin@xxxxxxx, akpm@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, jeremy@xxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, sunil.mushran@xxxxxxxxxx, chris.mason@xxxxxxxxxx, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Schwidefsky <schwidefsky@xxxxxxxxxx>, dave.mccracken@xxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, alan@xxxxxxxxxxxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> |
Delivery-date: |
Sun, 12 Jul 2009 10:16:23 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<a09e4489-a755-46e7-a569-a0751e0fc39f@default> |
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: |
<a09e4489-a755-46e7-a569-a0751e0fc39f@default> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 |
On 07/12/2009 07:20 PM, Dan Magenheimer wrote:
that information; but tmem is trying to go a step further by making
the cooperation between the OS and hypervisor more explicit
and directly beneficial to the OS.
KVM definitely falls into the camp of trying to minimize
modification to the guest.
No argument there. Well, maybe one :-) Yes, but KVM
also heavily encourages unmodified guests. Tmem is
philosophically in favor of finding a balance between
things that work well with no changes to any OS (and
thus work just fine regardless of whether the OS is
running in a virtual environment or not), and things
that could work better if the OS is knowledgable that
it is running in a virtual environment.
CMM2 and tmem are not any different in this regard; both require OS
modification, and both make information available to the hypervisor. In
fact CMM2 is much more intrusive (but on the other hand provides much
more information).
For those that believe virtualization is a flash-in-
the-pan, no modifications to the OS is the right answer.
For those that believe it will be pervasive in the
future, finding the right balance is a critical step
in operating system evolution.
You're arguing for CMM2 here IMO.
Is it the tmem API or the precache/preswap API layered on
top of it that is problematic? Both currently assume copying
but perhaps the precache/preswap API could, with minor
modifications, meet KVM's needs better?
My take on this is that precache (predecache?) / preswap can be
implemented even without tmem by using write-through backing for the
virtual disk. For swap this is actually slight;y more efficient than
tmem preswap, for preuncache slightly less efficient (since there will
be some double caching). So I'm more interested in other use cases of
tmem/CMM2.Well, first, tmem's very name means memory that is "beyond the
range of normal perception". This is certainly not the first class
of memory in use in data centers that can't be accounted at
process granularity. I'm thinking disk array caches as the
primary example. Also lots of tools that work great in a
non-virtualized OS are worthless or misleading in a virtual
environment.
Right, the transient uses of tmem when applied to disk objects
(swap/pagecache) are very similar to disk caches. Which is why you can
get a very similar effect when caching your virtual disks; this can be
done without any guest modification.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|