Re: [Xen-devel] Kernel 3.11 / 3.12 OOM killer and Xen ballooning

[James Dingwall <james.dingwall@xxxxxxxxxxx>]

Daniel Kiper wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 11:56:54AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 29, 2014 at 02:45:24PM +0000, James Dingwall wrote:
> > > Bob Liu wrote:
> > > > On 01/29/2014 01:15 AM, James Dingwall wrote:
> > > > > Bob Liu wrote:
> > > > > > I have made a patch by reserving extra 10% of original total memory, by
> > > > > > this way I think we can make the system much more reliably in all cases.
> > > > > > Could you please have a test? You don't need to set
> > > > > > selfballoon_reserved_mb by yourself any more.
> > > > > I have to say that with this patch the situation has definitely
> > > > > improved.  I have been running it with 3.12.[78] and 3.13 and pushing it
> > > > > quite hard for the last 10 days or so.  Unfortunately yesterday I got an
> > > > Good news!
> > > >
> > > > > OOM during a compile (link) of webkit-gtk.  I think your patch is part
> > > > > of the solution but I'm not sure if the other bit is simply to be more
> > > > > generous with the guest memory allocation or something else.  Having
> > > > > tested with memory = 512  and no tmem I get an OOM with the same
> > > > > compile, with memory = 1024 and no tmem the compile completes ok (both
> > > > > cases without maxmem).  As my domains are usually started with memory =
> > > > > 512 and maxmem = 1024 it seems that there should be sufficient with my
> Hmmm... James, how do you build webkit-gtk? Just simple "make" or "make -j"?
> Could you confirm that webkit-gtk in any "subjobs" do not use "make -j"?
My guest domain is Gentoo and I have MAKEOPTS="-j2" set in make.conf and 
according to the build log for webkit-gtk this is used unchanged:
>>> Source configured.
>>> Compiling source in 
/var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4 ...
make -j2

I wouldn't read anything in particular to it being webkit as I have seen 
similar from other large compiles (gcc, glibc, kdelibs, ...)
> > > > But I think from the beginning tmem/balloon driver can't expand guest
> > > > memory from size 'memory' to 'maxmem' automatically.
> > > I am carrying this patch for libxl (4.3.1) because maxmem wasn't
> > > being honoured.
> James, what do you mean by "maxmem wasn't being honoured"?
http://lists.xen.org/archives/html/xen-devel/2013-10/msg02228.html - the 
guest would never balloon above the value of memory when maxmem was set 
and was > memory in the configuration file.  There were some discussions 
about the correctness of this patch but the only place I could see an 
impact of maxmem was the parsing of the config parameters for the setup 
of the guest domain. IIRC the xl mem-max command which changes the same 
parameter once the guest domain is running resulted with the balloon up 
behaviour to max-mem working as expected. So the discrepancy between how 
xl behaves with the maxmem in the config or the execution of xl mem-max 
was what I had noted and what this patch resolved.  It would be easy to 
repeat those tests if necessary.
James
> > Daniel,
> >
> > Weren't you working on a similar patch? Do you recall what happend to it?
> Yep, and it was not applied because it has not been so mature. Additionally,
> this patch is part of bigger puzzle. I have it on my todo list but I would
> like to finish EFI stuff first. However, if you wish I could back to this
> work (if it is more important then EFI right now).
>
> Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel