From: Bob Liu <bob.liu@oracle.com>
To: James Dingwall <james.dingwall@zynstra.com>
Cc: xen-devel@lists.xen.org
Subject: Re: Kernel 3.11 / 3.12 OOM killer and Xen ballooning
Date: Wed, 15 Jan 2014 22:41:15 +0800 [thread overview]
Message-ID: <52D69E0B.5020006@oracle.com> (raw)
In-Reply-To: <52D64B87.6000400@zynstra.com>
On 01/15/2014 04:49 PM, James Dingwall wrote:
> Bob Liu wrote:
>> On 01/07/2014 05:21 PM, James Dingwall wrote:
>>> Bob Liu wrote:
>>>> Could you confirm that this problem doesn't exist if loading tmem with
>>>> selfshrinking=0 during compile gcc? It seems that you are compiling
>>>> difference packages during your testing.
>>>> This will help to figure out whether selfshrinking is the root cause.
>>> Got an oom with selfshrinking=0, again during a gcc compile.
>>> Unfortunately I don't have a single test case which demonstrates the
>>> problem but as I mentioned before it will generally show up under
>>> compiles of large packages such as glibc, kdelibs, gcc etc.
>>>
>> So the root cause is not because enabled selfshrinking.
>> Then what I can think of is that the xen-selfballoon driver was too
>> aggressive, too many pages were ballooned out which causeed heavy memory
>> pressure to guest OS.
>> And kswapd started to reclaim page until most of pages were
>> unreclaimable(all_unreclaimable=yes for all zones), then OOM Killer was
>> triggered.
>> In theory the balloon driver should give back ballooned out pages to
>> guest OS, but I'm afraid this procedure is not fast enough.
>>
>> My suggestion is reserve a min memory for your guest OS so that the
>> xen-selfballoon won't be so aggressive.
>> You can do it through parameters selfballoon_reserved_mb or
>> selfballoon_min_usable_mb.
> I am still getting OOM errors with both of these set to 32 so I'll try
> another bump to 64. I think that if I do find values which prevent it
> though then it is more of a work around than a fix because it still
> suggests that swap is not being used when ballooning is no longer
Yes, it's like a work around. But I don't think there is a better way.
>From the recent OOM log your reported:
[ 8212.940769] Free swap = 1925576kB
[ 8212.940770] Total swap = 2097148kB
[504638.442136] Free swap = 1868108kB
[504638.442137] Total swap = 2097148kB
171572KB and 229040KB data are swapped out to swap disk, I think there
are already significantly values for guest OS has only ~300M usable memory.
guest OS can't find out pages suitable for swap any more after so many
pages are swapped out, although at that time the swap device still have
enough space.
The OOM may not be triggered if the balloon driver can give back memory
to guest OS fast enough but I think it's unrealistic.
So the best way is reserve more memory to guest OS.
> capable of satisfying the request. I've also got an Ubuntu Saucy (3.11
> kernel) guest running on the dom0 with tmem activated so I'm going to
> see if I can find a comparable workload to see if I get the same issue
> with a different kernel configuration.
>
> James
--
Regards,
-Bob
next prev parent reply other threads:[~2014-01-15 14:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 17:50 Kernel 3.11 / 3.12 OOM killer and Xen ballooning James Dingwall
2013-12-09 21:48 ` Konrad Rzeszutek Wilk
2013-12-10 14:52 ` James Dingwall
2013-12-10 15:27 ` Konrad Rzeszutek Wilk
2013-12-11 7:22 ` Bob Liu
2013-12-11 9:25 ` James Dingwall
2013-12-11 9:54 ` Bob Liu
2013-12-11 10:16 ` James Dingwall
2013-12-11 16:30 ` James Dingwall
2013-12-12 1:03 ` Bob Liu
2013-12-13 16:59 ` James Dingwall
2013-12-17 6:11 ` Bob Liu
2013-12-18 12:04 ` Bob Liu
2013-12-19 19:08 ` James Dingwall
2013-12-20 3:17 ` Bob Liu
2013-12-20 12:22 ` James Dingwall
2013-12-26 8:42 ` James Dingwall
2014-01-02 6:25 ` Bob Liu
2014-01-07 9:21 ` James Dingwall
2014-01-09 10:48 ` Bob Liu
2014-01-09 10:54 ` James Dingwall
2014-01-09 11:04 ` James Dingwall
2014-01-15 8:49 ` James Dingwall
2014-01-15 14:41 ` Bob Liu [this message]
2014-01-15 16:35 ` James Dingwall
2014-01-16 1:22 ` Bob Liu
2014-01-16 10:52 ` James Dingwall
2014-01-28 17:15 ` James Dingwall
2014-01-29 14:35 ` Bob Liu
2014-01-29 14:45 ` James Dingwall
2014-01-31 16:56 ` Konrad Rzeszutek Wilk
2014-02-03 9:49 ` Daniel Kiper
2014-02-03 10:30 ` Konrad Rzeszutek Wilk
2014-02-03 11:20 ` James Dingwall
2014-02-03 14:00 ` Daniel Kiper
2013-12-10 8:16 ` Jan Beulich
2013-12-10 14:01 ` James Dingwall
2013-12-10 14:25 ` Jan Beulich
2013-12-10 14:52 ` James Dingwall
2013-12-10 14:59 ` Jan Beulich
2013-12-10 15:16 ` James Dingwall
-- strict thread matches above, loose matches on Subject: below --
2013-11-21 11:28 James Dingwall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D69E0B.5020006@oracle.com \
--to=bob.liu@oracle.com \
--cc=james.dingwall@zynstra.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.