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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Except for xm dmesg being pretty filled with messages (could be due to loglvl 
all):

(XEN) [2011-01-16 12:48:33] tmem: all pools frozen for all domains
(XEN) [2011-01-16 12:48:33] tmem: all pools thawed for all domains
(XEN) [2011-01-16 12:48:44] tmem: all pools frozen for all domains
(XEN) [2011-01-16 12:48:44] tmem: all pools thawed for all domains
etc. etc. etc.

I haven't seen any problems so far (without enabling it in guests and testing 
the actual functionality)

--
Sander



Wednesday, January 19, 2011, 10:38:09 PM, you wrote:

>> 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





-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


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