WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] less verbose tmem, was: tmem_relinquish_page: fa

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] less verbose tmem, was: tmem_relinquish_page: failing order=<n>
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 7 Jan 2010 09:51:57 -0800 (PST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 07 Jan 2010 10:08:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B4606B80200007800028A8C@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
(apologies if this is a repeat; having email problems)

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Subject: Re: [PATCH] less verbose tmem, was: tmem_relinquish_page:
> failing order=<n>
> 
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 06.01.10 18:13 >>>
> >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
> 
> What makes you think so? Iirc there are several xmalloc()-s of more
> than a page in size (which ultimately will call alloc_heap_pages()),
> and those usually don't have a fallback.

I don't know this for a fact, but had discussed it in xen-devel
some time ago (maybe over a year ago).   Since tmem doesn't do
anything until at least one tmem-modified guest uses it, the only
issue is if launching a subsequent domain requires an allocation
of order>0.  Since Xen doesn't have any kind of memory defragmenter,
any such requirement is perilous at best.

> >no reason for the message to be logged in a released Xen
> >so here's a patch to ifndef NDEBUG the printk.
> 
> Even in a debug build this may be really annoying: On NUMA machines,
> the dma_bitsize mechanism (to avoid exhausting DMA memory) can
> cause close to 2000 of these messages when allocating Dom0's
> initial memory (in the absence of a severely restricting dom0_mem,
> and with node 0 spanning 4G or more). This makes booting
> unacceptably slow, especially when using a graphical console mode.

OK, I can take the patch one step further by only doing the
printk if tmem has been used at least once.  Let me take a
look at that.

Dan

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