All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Rik van Riel <riel@redhat.com>,
	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, 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: Sun, 12 Jul 2009 20:16:01 +0300	[thread overview]
Message-ID: <4A5A1A51.2080301@redhat.com> (raw)
In-Reply-To: <a09e4489-a755-46e7-a569-a0751e0fc39f@default>

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.


WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Rik van Riel <riel@redhat.com>,
	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, 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: Sun, 12 Jul 2009 20:16:01 +0300	[thread overview]
Message-ID: <4A5A1A51.2080301@redhat.com> (raw)
In-Reply-To: <a09e4489-a755-46e7-a569-a0751e0fc39f@default>

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.

--
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>

  reply	other threads:[~2009-07-12 17:16 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-07 16:17 [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux Dan Magenheimer
2009-07-07 16:17 ` Dan Magenheimer
2009-07-07 17:28 ` Rik van Riel
2009-07-07 17:28   ` Rik van Riel
2009-07-07 19:53   ` Dan Magenheimer
2009-07-07 19:53     ` Dan Magenheimer
2009-07-08 22:56 ` Anthony Liguori
2009-07-08 22:56   ` Anthony Liguori
2009-07-08 23:31   ` [Xen-devel] " Dan Magenheimer
2009-07-08 23:31     ` Dan Magenheimer
2009-07-08 23:57     ` Anthony Liguori
2009-07-08 23:57       ` Anthony Liguori
2009-07-09  0:17       ` Jeremy Fitzhardinge
2009-07-09  0:17         ` Jeremy Fitzhardinge
2009-07-09  0:27         ` Anthony Liguori
2009-07-09  0:27           ` Anthony Liguori
2009-07-09  1:20   ` Rik van Riel
2009-07-09  1:20     ` Rik van Riel
2009-07-09 21:09     ` Dan Magenheimer
2009-07-09 21:09       ` Dan Magenheimer
2009-07-09 21:27       ` Rik van Riel
2009-07-09 21:27         ` Rik van Riel
2009-07-09 21:48         ` Dan Magenheimer
2009-07-09 21:48           ` Dan Magenheimer
2009-07-09 21:41       ` Anthony Liguori
2009-07-09 21:41         ` Anthony Liguori
2009-07-09 22:34         ` Dan Magenheimer
2009-07-09 22:34           ` Dan Magenheimer
2009-07-09 22:45           ` Rik van Riel
2009-07-09 22:45             ` Rik van Riel
2009-07-09 23:33           ` Anthony Liguori
2009-07-09 23:33             ` Anthony Liguori
2009-07-09 23:33             ` Anthony Liguori
2009-07-10 15:23             ` Dan Magenheimer
2009-07-10 15:23               ` Dan Magenheimer
2009-07-12  9:20               ` Avi Kivity
2009-07-12  9:20                 ` Avi Kivity
2009-07-12 16:28                 ` Dan Magenheimer
2009-07-12 16:28                   ` Dan Magenheimer
2009-07-12 17:27                   ` Avi Kivity
2009-07-12 17:27                     ` Avi Kivity
2009-07-12 20:59                     ` Dan Magenheimer
2009-07-12 20:59                       ` Dan Magenheimer
2009-07-12 13:28               ` Anthony Liguori
2009-07-12 13:28                 ` Anthony Liguori
2009-07-12 16:20                 ` Dan Magenheimer
2009-07-12 16:20                   ` Dan Magenheimer
2009-07-12 17:16                   ` Avi Kivity [this message]
2009-07-12 17:16                     ` Avi Kivity
2009-07-12 19:34                     ` Anthony Liguori
2009-07-12 19:34                       ` Anthony Liguori
2009-07-13 20:17                       ` Chris Mason
2009-07-13 20:17                         ` Chris Mason
2009-07-13 20:38                         ` Anthony Liguori
2009-07-13 20:38                         ` Anthony Liguori
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:01                             ` Chris Mason
2009-07-13 21:17                             ` Anthony Liguori
2009-07-13 21:17                               ` Anthony Liguori
2009-07-26 15:00                               ` Avi Kivity
2009-07-26 15:00                                 ` Avi Kivity
2009-07-13 21:17                             ` Anthony Liguori
2009-07-12 20:39                     ` [Xen-devel] " Dan Magenheimer
2009-07-12 20:39                       ` Dan Magenheimer
2009-07-12 20:43                       ` Avi Kivity
2009-07-12 20:43                         ` Avi Kivity
2009-07-12 21:08                         ` Dan Magenheimer
2009-07-12 21:08                           ` Dan Magenheimer
2009-07-13 11:33                           ` Avi Kivity
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=4A5A1A51.2080301@redhat.com \
    --to=avi@redhat.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anthony@codemonkey.ws \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=chris.mason@oracle.com \
    --cc=dan.magenheimer@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.