From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Dingwall Subject: Re: Kernel 3.11 / 3.12 OOM killer and Xen ballooning Date: Mon, 3 Feb 2014 11:20:33 +0000 Message-ID: <52EF7B81.4080601@zynstra.com> References: <52CBC700.1060602@zynstra.com> <52CE7E67.5080708@oracle.com> <52D64B87.6000400@zynstra.com> <52D69E0B.5020006@oracle.com> <52D6B8B6.5070302@zynstra.com> <52D7346A.3000300@oracle.com> <52E7E594.2050104@zynstra.com> <52E911CA.9020700@oracle.com> <52E91404.30602@zynstra.com> <20140131165654.GF23648@phenom.dumpdata.com> <20140203094912.GA5273@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140203094912.GA5273@olila.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper , Konrad Rzeszutek Wilk Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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