From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasiliy G Tolstov Subject: Re: [RFC] tmem ABI change... backwards compatibility unnecessary? Date: Wed, 01 Sep 2010 18:44:08 +0400 Message-ID: <1283352248.5953.46.camel@vase.work> References: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default> Reply-To: v.tolstov@selfip.ru Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: Jeremy Fitzhardinge , "Xen-Devel (xen-devel@lists.xensource.com)" , tmem-devel@oss.oracle.com, kurt.hackel@oracle.com, Jan Beulich , stephen.spector@citrix.com, Keir Fraser , Chris, xen-users@lists.xensource.com, Mason List-Id: xen-devel@lists.xenproject.org =D0=92 =D0=A1=D1=80=D0=B4, 01/09/2010 =D0=B2 07:36 -0700, Dan Magenheimer= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Tmem users and Xen developers/distros -- >=20 > (Please forward/repost as you see fit.) >=20 > After a great deal of discussion and review with linux > kernel developers, it appears there are "next-generation" > filesystems (such as btrfs, xfs, Lustre) that will not > be able to use tmem due to an ABI limitation... a field > that represents a unique file identifier is 64-bits in > the tmem ABI and may need to be as large as 192-bits. > So to support these guest filesystems, the tmem ABI must be > revised, from "v0" to "v1". >=20 > I *think* it is still the case that tmem is experimental > and is not used anywhere yet in production. If I am > wrong, PLEASE LET ME KNOW ASAP. >=20 > The tmem ABI is designed to support multiple revisions, > so the Xen tmem implementation could be updated to > handle both v0 and v1. However this is a bit > messy and would require data structures for both v0 > and v1 to appear in public Xen header files. >=20 > I am inclined to update the Xen tmem implementation > to only support v1 and gracefully fail v0. This would > result in only a performance loss (as if tmem were > disabled) for newly launched tmem-v0-enabled guests, > but live-migration between old tmem-v0 Xen and new > tmem-v1 Xen machines would fail, and saved tmem-v0 > guests will not be able to be restored on a tmem-v1 > Xen machine. I would plan to update both pre-4.0.2 > and unstable (future 4.1) to only support v1. >=20 > I believe these restrictions are reasonable at this > point in the tmem lifecycle, though they may not > be reasonable in the near future; should the tmem > ABI need to be revised from v1 to v2, I understand > backwards compatibility will be required. >=20 > Comments or questions? (If agreeable, positive public > acks appreciated.) Thank You, Dan. What needed to do, to use tmem v1? Does it needed to recompile dom0 kernel, or only domU kernel affected by change? --=20 Vasiliy G Tolstov Selfip.Ru