RE: OOM problems

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Mon, 15 Nov 2010, Jan Beulich wrote:
> >>> On 13.11.10 at 10:13, Ian Pratt <Ian.Pratt@eu.citrix.com> 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.