From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [PATCH] Re: tmem on 4.1 (was Re: Freeze schedule) Date: Wed, 19 Jan 2011 13:38:09 -0800 (PST) Message-ID: <8a563a46-bdbb-407f-9455-2eaedc773dfc@default> References: <19756.36855.379911.131550@mariner.uk.xensource.com> <19756.41312.418212.882349@mariner.uk.xensource.com4D2D7106020000780002BF02@vpn.id2.novell.com> <4D2D7106020000780002BF02@vpn.id2.novell.com> <1eeeb215-4222-43af-aca2-8d0787015058@default> <4D2ECA37020000780002C2B9@vpn.id2.novell.com 20110119165349.GF8286@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20110119165349.GF8286@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Keir Fraser Cc: Ian, xen-devel@lists.xensource.com, Jackson , Jan Beulich List-Id: xen-devel@lists.xenproject.org > Subject: [PATCH] Re: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule) > Disable tmem by default for 4.1 release. >=20 > Although one major source of order>0 allocations has been removed, > others still remain, so re-disable tmem until the issue can be fixed > properly. >=20 > Signed-off-by: Tim Deegan >=20 > diff -r fe8a177ae9cb -r 497a764d9314 xen/common/tmem_xen.c > --- a/xen/common/tmem_xen.c=09Wed Jan 19 15:29:04 2011 +0000 > +++ b/xen/common/tmem_xen.c=09Wed Jan 19 16:47:57 2011 +0000 > @@ -15,7 +15,7 @@ >=20 > #define EXPORT /* indicates code other modules are dependent upon */ >=20 > -EXPORT bool_t __read_mostly opt_tmem =3D 1; > +EXPORT bool_t __read_mostly opt_tmem =3D 0; > boolean_param("tmem", opt_tmem); Just to check again, has anyone actually seen a problem with tmem enabled by default recently? I agree that there is still theoretically a problem, but there is the same problem with normal guests doing lots of ballooning as well. Also, note that even if tmem defaults to enabled, the problem is impossible unless a guest enables tmem (or, in the case of SuSE, dom0). And even if a guest does enable tmem, the problem manifested largely due to shadow pages using order>0 (now fixed?)... failure on domain creation can happen for many reasons and is much less of an issue, true? Feel free to shoot me down with more evidence, but I have to at least provide token resistance to this patch. Distros might certainly choose to disable it to avoid any risk at all, but turning it off anymore seems overkill for xen.org open source Xen IMHO. Dan