|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] [PATCH] less verbose tmem, was: tmem_relinquish_page: failin
> -----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;
}
tmem-norelinq-printk.patch
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|