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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.12.13 at 15:01, James Dingwall <james.dingwall@xxxxxxxxxxx> wrote:
> Jan Beulich wrote:
>>>>> On 09.12.13 at 18:50, James Dingwall <james.dingwall@xxxxxxxxxxx> wrote:
>>> Since 3.11 I have noticed that the OOM killer quite frequently triggers
>>> in my Xen guest domains which use ballooning to increase/decrease their
>>> memory allocation according to their requirements.  One example domain I
>>> have has a maximum memory setting of ~1.5Gb but it usually idles at
>>> ~300Mb, it is also configured with 2Gb swap which is almost 100% free.
>>>
>>> # free
>>>                total       used       free     shared    buffers cached
>>> Mem:        272080     248108      23972          0 1448      63064
>>> -/+ buffers/cache:     183596      88484
>>> Swap:      2097148          8    2097140
>>>
>>> There is plenty of available free memory in the hypervisor to balloon to
>>> the maximum size:
>>> # xl info | grep free_mem
>>> free_memory            : 14923
>> But you don't tell us how you trigger the process of re-filling
>> memory. Yet that's the crucial point here; the fact that there is
>> enough memory available in the hypervisor is only a necessary
>> prerequisite.
> My guest systems are Gentoo based and most often the problems happen 
> while running emerge (Python script).  The example trace was taken from 
> an emerge command launched via a cron script which runs emerge --sync ; 
> emerge --deep --newuse -p -u world.  Almost all the other times I have 
> seen the behaviour have been during emerge --deep --newuse -u world 
> runs, most often during the build of large packages such as kdelibs, 
> seamonkey or libreoffice.  However occasionally I have seen it with 
> smaller builds or during the package merge phase where files are indexed 
> and copied in to the live filesystem.

I don't think I understand what you're trying to tell me, or in what
way this answers the question.

> I have done some testing with the program below which successfully fills 
> all memory and swap before being killed.  One thought I had was that 
> perhaps there was some issue around a balloon down/up when the rate at 
> which memory is being requested and released is high.  I will try 
> another program with a random pattern of malloc/free to see if I can 
> make a test case to help with a bisect.

Again - the question is not how to drive your system out of
memory, but what entity (if any) it is that is supposed to react on
memory becoming tight and triggering the balloon driver to re-
populate pages. One such thing could be xenballoond (which is
gone in the unstable tree, i.e. what is to become 4.4).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel