Re: Re: 2.6.32 pvops dom0 oom when creating a domU

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Aug 02, 2011 at 07:59:03AM +0300, Pasi Kärkkäinen wrote:
> On Mon, Aug 01, 2011 at 11:19:25PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Aug 02, 2011 at 01:57:53AM +0200, Daniel Musketa wrote:
> > > 2011/8/2 Daniel Musketa <daniel.musketa@googlemail.com>:
> > > > Maybe I should say more about memory usage:
> > > 
> > > I got even more detailled logs for you in the attached file:
> > > 
> > > line   3: dom0 memory: 2,560 M
> > > line  20: 21,637 M free
> > > line  34: dom0_mem=4000M
> > > line  47: domU memory = '2800'
> > > line  72: OOM begins
> > > line 157: key 'm' on (XEN) console
> > 
> > Try the 'mem=4G' in your Linux line (along with the one in your hypervisor).
> > The problem is that Dom0 sets up pagetables for the 32GB even thought it is never
> > going to use it - the 'mem=4G' should fix that for you.
> > 
> 
> Hmm.. Does that explain the dom0 OOM ? Why does dom0 OOM when creating a domU ?
> In this case dom0 didn't have to be ballooned down, it shouldn't see any changes to its memory? 

So Linux kernel looks at the E820 and sees 30GB of "reserved" memory (that memory is
what dom0 "thinks" it might balloon too - even thought it won't ever do). So Linux thinks
to itself: "OK, we _might_ use that in the future, so lets create the pagetables for it".
And we end up with 800MBs (or more) of pagetables that never end up using. That 800MB does not
get released or what not. So your dom0 ends up with 300MB or so (say with dom0_mem=max:1G)
and we end up with the OOM happily killing things.

The idea, now that Daniel Kipper's patches are in - to use the memory hotplug API to balloon
pages in and out. That should make this much easier.

> 
> Just trying to understand it better :) 

Of course. Thanks for asking!
> 
> -- Pasi
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel