[Xen-devel] [PATCH] less verbose tmem, was: tmem_relinquish_page: failing order=<n>

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Subject: tmem_relinquish_page: failing order=<n> 
> Dan,
> 
> having taken a fresh snapshot of xen-unstable today, I start 
> seeing quite
> a number of these messages during late Xen and early Dom0 boot. They
> don't seem to be very meaningful (according to the stack traces I
> created for some of them to understand where they originate), hence I
> wonder whether they couldn't get silenced.

Hi Jan --

The message is relevant if any code calling alloc_heap_pages()
for order>0 isn't able to fallback to order=0.  All usages today
in Xen can fallback, but future calls may not, so I'd prefer
to keep the printk there at least in xen-unstable.  BUT there's
no reason for the message to be logged in a released Xen
so here's a patch to ifndef NDEBUG the printk.

NOTE TO KEIR: Reminder that cset 19939 causes debug=y to
be the default build so you'll need to turn that off
before the final 4.0.0 bits (and/or turn it back on after
xen-unstable forks for 4.0.0).

Signed-off by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>

diff -r 4feec90815a0 xen/common/tmem.c
--- a/xen/common/tmem.c Tue Jan 05 08:40:18 2010 +0000
+++ b/xen/common/tmem.c Wed Jan 06 10:08:01 2010 -0700
@@ -2483,7 +2483,9 @@ EXPORT void *tmem_relinquish_pages(unsig
     relinq_attempts++;
     if ( order > 0 )
     {
+#ifndef NDEBUG
         printk("tmem_relinquish_page: failing order=%d\n", order);
+#endif
         return NULL;
     }

Attachment: tmem-norelinq-printk.patch
Description: Binary data

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