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

RE: [Xen-devel] OOM problems

On Mon, 15 Nov 2010, Jan Beulich wrote:
> >>> On 13.11.10 at 10:13, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx> wrote:
> >>   > What do the guests use for storage? (e.g. "blktap2 for VHD files on
> >> an iscsi mounted ext3 volume")
> >> 
> >> Simple sparse .img files on a local ext4 RAID volume, using "file:".
> > 
> > Ah, if you're using loop it may be that you're just filling memory with 
> > dirty pages. Older kernels certainly did this, not sure about newer ones.
> 
> Shouldn't this lead to the calling process being throttled, instead of
> the system running into OOM?
> 
> Further, having got reports of similar problems lately, too, we have
> indications that using pv drivers also gets us around the issue,
> which makes me think that it's rather qemu-dm misbehaving (and
> not getting stopped doing so by the kernel for whatever reason -
> possibly just missing some non-infinite rlimit setting).
> 
> Not knowing much about the workings of stubdom, one thing I
> don't really understand is how qemu-dm in Dom0 would be
> heavily resource consuming here (actually I would have expected
> no qemu-dm in Dom0 at all in this case). Aren't the main I/O paths
> going from qemu-stubdom directly to the backends?
> 

Qemu-dm in a stubdom uses the blkfront and netfront drivers in
Minios to communicate with the backends in dom0.
In a stubdom-only scenario qemu-dm in dom0 only provides the xenfb
backend for the vesa framebuffer.

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

<Prev in Thread] Current Thread [Next in Thread>