This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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

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


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