linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Rik van Riel <riel@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	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:48:10 -0700 (PDT)	[thread overview]
Message-ID: <fa083462-f28d-4188-9006-a285141acc21@default> (raw)
In-Reply-To: <4A5660CB.5080607@redhat.com>

> > 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.
> 
> Indeed.  Tmem and auto-ballooning have a simple mechanism,
> but the policy required to make it work right could well
> be too complex to ever get right.
> 
> CMM2 has a more complex mechanism, but the policy is
> absolutely trivial.

Could you elaborate a bit more on what policy you
are referring to and what decisions the policies are
trying to guide?  And are you looking at the policies
in Linux or in the hypervisor or the sum of both?

The Linux-side policies in the tmem patch seem trivial
to me and the Xen-side implementation is certainly
working correctly, though "working right" is a hard
objective to measure.  But depending on how you define
"working right", the pageframe replacement algorithm
in Linux may also be "too complex to ever get right"
but it's been working well enough for a long time.

> CMM2 and auto-ballooning seem to give about similar
> performance gains on zSystem.

Tmem provides a huge advantage over my self-ballooning
implementation, but maybe that's because it is more
aggressive than the CMM auto-ballooning, resulting
in more refaults that must be "fixed".

> I suspect that for Xen and KVM, we'll want to choose
> for the approach that has the simpler policy, because
> relying on different versions of different operating
> systems to all get the policy of auto-ballooning or
> tmem right is likely to result in bad interactions
> between guests and other intractable issues.

Again, not sure what tmem policy in Linux you are referring
to or what bad interactions you foresee.  Could you
clarify?

Auto-ballooning policy is certainly a challenge, but
that's true whether CMM or tmem, right?

Thanks,
Dan

--
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-09 21:29 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
2009-07-09 21:27       ` Rik van Riel
2009-07-09 21:48         ` Dan Magenheimer [this message]
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 21:01                           ` Chris Mason
2009-07-13 21:17                             ` Anthony Liguori
2009-07-26 15:00                               ` Avi Kivity
2009-07-13 20:38                         ` Anthony Liguori
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=fa083462-f28d-4188-9006-a285141acc21@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