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