[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.