From: Piotr Nowojski <piotr.nowojski@adocean-global.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: OOM Killer and add_to_page_cache_locked
Date: Tue, 11 Jun 2013 10:35:01 +0200 [thread overview]
Message-ID: <51B6E135.2020409@adocean-global.com> (raw)
In-Reply-To: <20130607153635.GJ8117@dhcp22.suse.cz>
W dniu 07.06.2013 17:36, Michal Hocko pisze:
> On Fri 07-06-13 17:13:55, Piotr Nowojski wrote:
>> W dniu 06.06.2013 17:57, Michal Hocko pisze:
>>>>> In our system we have hit some very annoying situation (bug?) with
>>>>> cgroups. I'm writing to you, because I have found your posts on
>>>>> mailing lists with similar topic. Maybe you could help us or point
>>>>> some direction where to look for/ask.
>>>>>
>>>>> We have system with ~15GB RAM (+2GB SWAP), and we are running ~10
>>>>> heavy IO processes. Each process is using constantly 200-210MB RAM
>>>>> (RSS) and a lot of page cache. All processes are in cgroup with
>>>>> following limits:
>>>>>
>>>>> /sys/fs/cgroup/taskell2 $ cat memory.limit_in_bytes
>>>>> memory.memsw.limit_in_bytes
>>>>> 14183038976
>>>>> 15601344512
>>> I assume that memory.use_hierarchy is 1, right?
>> System has been rebooted since last test, so I can not guarantee
>> that it was set for 100%, but it should have been. Currently I'm
>> rerunning this scenario that lead to the described problem with:
>>
>> /sys/fs/cgroup/taskell2# cat memory.use_hierarchy ../memory.use_hierarchy
>> 1
>> 0
> OK, good. Your numbers suggeste that the hierachy _is_ in use. I just
> wanted to be 100% sure.
>
I don't know what has solved this problem, but we weren't able to
reproduce this problem during whole weekend. Most likely there was some
problem with our code initializing cgroups configuration regarding
use_hierarchy (can writing 1 to memory.use_hierarchy silently fail?). I
have added assertions for checking this parameter before starting and
after initialization of our application. If problem reoccur, I will
proceed as you suggested before - trying latest kernels.
Thanks, Piotr Nowojski
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-06-11 8:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51B05616.9050501@adocean-global.com>
2013-06-06 15:57 ` Michal Hocko
2013-06-07 15:13 ` Piotr Nowojski
2013-06-07 15:36 ` Michal Hocko
2013-06-11 8:35 ` Piotr Nowojski [this message]
2013-06-11 9:49 ` Michal Hocko
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=51B6E135.2020409@adocean-global.com \
--to=piotr.nowojski@adocean-global.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox