linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: Austin Kim <austincrashtool@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: 答复: Too easy OOM
Date: Wed, 28 Mar 2018 01:34:24 +0000	[thread overview]
Message-ID: <2AD939572F25A448A3AE3CAEA61328C237512B38@BC-MAIL-M28.internal.baidu.com> (raw)
In-Reply-To: <CAKEcN828eqXN8zhKgzu+Mf-vdXC8o_LOmxwWZ4vayrdvmpdPFQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

OK, I see this commit, I will test the latest kernel

commit 1c610d5f93c709df56787f50b3576704ac271826
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Mar 22 16:17:42 2018 -0700

    mm/vmscan: wake up flushers for legacy cgroups too

    Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter dirty
    pages on the LRU") added flusher invocation to shrink_inactive_list()
    when many dirty pages on the LRU are encountered.

    However, shrink_inactive_list() doesn't wake up flushers for legacy
    cgroup reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove old
    flusher wakeup from direct reclaim path") removed the only source of
    flusher's wake up in legacy mem cgroup reclaim path.

    This leads to premature OOM if there is too many dirty pages in cgroup:
        # mkdir /sys/fs/cgroup/memory/test
        # echo $$ > /sys/fs/cgroup/memory/test/tasks
        # echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes
        # dd if=/dev/zero of=tmp_file bs=1M count=100
        Killed

        dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0

        Call Trace:
         dump_stack+0x46/0x65
         dump_header+0x6b/0x2ac
         oom_kill_process+0x21c/0x4a0
         out_of_memory+0x2a5/0x4b0
         mem_cgroup_out_of_memory+0x3b/0x60
         mem_cgroup_oom_synchronize+0x2ed/0x330
         pagefault_out_of_memory+0x24/0x54
         __do_page_fault+0x521/0x540
         page_fault+0x45/0x50

        Task in /test killed as a result of limit of /test
        memory: usage 51200kB, limit 51200kB, failcnt 73
        memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0
        kmem: usage 296kB, limit 9007199254740988kB, failcnt 0
        Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB
                mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB
                active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB
        Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child
        Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB
        oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Wake up flushers in legacy cgroup reclaim too.




发件人: Austin Kim [mailto:austincrashtool@gmail.com]
发送时间: 2018年3月27日 21:44
收件人: Li,Rongqing <lirongqing@baidu.com>
抄送: linux-mm@kvack.org; linux-kernel@vger.kernel.org
主题: Re: Too easy OOM

Would you please specify the Linux Kernel version with reproducing rate?

If possible, please share the kernel log with .config.

BR
Austin Kim
2018년 3월 27일 (화) 오후 6:19, Li,Rongqing <lirongqing@baidu.com<mailto:lirongqing@baidu.com>>님이 작성:
Current kernel version is too easy to trigger OOM, is it normal?

# echo $$ > /cgroup/test/tasks
# echo 200000000 >/cgroup/test/memory.limit_in_bytes
# dd if=aaa  of=bbb  bs=1k count=3886080
Killed

[-- Attachment #2: Type: text/html, Size: 17196 bytes --]

  parent reply	other threads:[~2018-03-28  1:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27  9:19 Li,Rongqing
2018-03-27 13:43 ` Austin Kim
2018-03-28  1:20   ` 答复: " Li,Rongqing
2018-03-28  1:34   ` Li,Rongqing [this message]
2018-03-28 12:58     ` 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=2AD939572F25A448A3AE3CAEA61328C237512B38@BC-MAIL-M28.internal.baidu.com \
    --to=lirongqing@baidu.com \
    --cc=austincrashtool@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox