RE: [PATCH] Re: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> Subject: [PATCH] Re: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule)

> Disable tmem by default for 4.1 release.
> 
> 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.
> 
> Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> 
> diff -r fe8a177ae9cb -r 497a764d9314 xen/common/tmem_xen.c
> --- a/xen/common/tmem_xen.c   Wed Jan 19 15:29:04 2011 +0000
> +++ b/xen/common/tmem_xen.c   Wed Jan 19 16:47:57 2011 +0000
> @@ -15,7 +15,7 @@
> 
>  #define EXPORT /* indicates code other modules are dependent upon */
> 
> -EXPORT bool_t __read_mostly opt_tmem = 1;
> +EXPORT bool_t __read_mostly opt_tmem = 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel