Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753151AbZGLVKa (ORCPT ); Sun, 12 Jul 2009 17:10:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751552AbZGLVKU (ORCPT ); Sun, 12 Jul 2009 17:10:20 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]:29150 "EHLO acsinet11.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751473AbZGLVKT convert rfc822-to-8bit (ORCPT ); Sun, 12 Jul 2009 17:10:19 -0400 MIME-Version: 1.0 Message-ID: Date: Sun, 12 Jul 2009 14:08:36 -0700 (PDT) From: Dan Magenheimer To: Avi Kivity Cc: npiggin@suse.de, akpm@osdl.org, jeremy@goop.org, xen-devel@lists.xensource.com, tmem-devel@oss.oracle.com, kurt.hackel@oracle.com, Rusty Russell , linux-kernel@vger.kernel.org, dave.mccracken@oracle.com, linux-mm@kvack.org, sunil.mushran@oracle.com, alan@lxorguk.ukuu.org.uk, Anthony Liguori , Schwidefsky , Marcelo Tosatti , chris.mason@oracle.com, Balbir Singh Subject: RE: [Xen-devel] Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux In-Reply-To: <4A5A4AF2.40609@redhat.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 1.5.1.2 (306040) [OL 9.0.0.6627] Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 8BIT X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A5A510C.005D:SCFSTAT5015188,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1284 Lines: 31 > >> 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. > > > > Write-through backing and virtual disk cacheing offer a > > similar effect, but it is far from the same. > > Can you explain how it differs for the swap case? Maybe I don't > understand how tmem preswap works. The key differences I see are the "please may I store something" API and the fact that the reply (yes or no) can vary across time depending on the state of the collective of guests. Virtual disk cacheing requires the host to always say yes and always deliver persistence. I can see that this is less of a concern for KVM because the host can swap... though doesn't this hide information from the guest and potentially have split-brain swapping issues? (thanks for the great discussion so far... going offline mostly now for a few days) Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/