Re: Kernel 3.11 / 3.12 OOM killer and Xen ballooning

[James Dingwall <james.dingwall@zynstra.com>]

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