From: Roman Gushchin <guro@fb.com>
To: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org, kernel-team@fb.com
Subject: Re: [PATCH v2] mm: memcg: update memcg OOM messages on cgroup2
Date: Mon, 6 Aug 2018 09:34:12 -0700 [thread overview]
Message-ID: <20180806163409.GA19960@castle> (raw)
In-Reply-To: <20180806161529.GA410235@devbig004.ftw2.facebook.com>
On Mon, Aug 06, 2018 at 09:15:29AM -0700, Tejun Heo wrote:
> mem_cgroup_print_oom_info() currently prints the same info for cgroup1
> and cgroup2 OOMs. It doesn't make much sense on cgroup2, which
> doesn't use memsw or separate kmem accounting - the information
> reported is both superflous and insufficient. This patch updates the
> memcg OOM messages on cgroup2 so that
>
> * It prints memory and swap usages and limits used on cgroup2.
>
> * It shows the same information as memory.stat.
>
> I took out the recursive printing for cgroup2 because the amount of
> output could be a lot and the benefits aren't clear. An example dump
> follows.
>
> [ 40.854197] stress invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oo0
> [ 40.855239] stress cpuset=/ mems_allowed=0
> [ 40.855665] CPU: 6 PID: 1990 Comm: stress Not tainted 4.18.0-rc7-work+ #281
> [ 40.856260] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
> [ 40.857000] Call Trace:
> [ 40.857222] dump_stack+0x5e/0x8b
> [ 40.857517] dump_header+0x74/0x2fc
> [ 40.859106] oom_kill_process+0x225/0x490
> [ 40.859449] out_of_memory+0x111/0x530
> [ 40.859780] mem_cgroup_out_of_memory+0x4b/0x80
> [ 40.860161] mem_cgroup_oom_synchronize+0x3ff/0x450
> [ 40.861334] pagefault_out_of_memory+0x2f/0x74
> [ 40.861718] __do_page_fault+0x3de/0x460
> [ 40.862347] page_fault+0x1e/0x30
> [ 40.862636] RIP: 0033:0x5566cd5aadd0
> [ 40.862940] Code: 0f 84 3c 02 00 00 8b 54 24 0c 31 c0 85 d2 0f 94 c0 89 04 24 41 83 fd 02 0f 8f f6
> [ 40.864558] RSP: 002b:00007ffd979ced40 EFLAGS: 00010206
> [ 40.865005] RAX: 0000000001f4f000 RBX: 00007f3a397d8010 RCX: 00007f3a397d8010
> [ 40.865615] RDX: 0000000000000000 RSI: 0000000004001000 RDI: 0000000000000000
> [ 40.866220] RBP: 00005566cd5abbb4 R08: 00000000ffffffff R09: 0000000000000000
> [ 40.866845] R10: 0000000000000022 R11: 0000000000000246 R12: ffffffffffffffff
> [ 40.867452] R13: 0000000000000002 R14: 0000000000001000 R15: 0000000004000000
> [ 40.868091] Task in /test-cgroup killed as a result of limit of /test-cgroup
> [ 40.868726] memory 33554432 (max 33554432)
> [ 40.869096] swap 0
> [ 40.869280] anon 32845824
> [ 40.869519] file 0
> [ 40.869730] kernel_stack 0
> [ 40.869966] slab 163840
> [ 40.870191] sock 0
> [ 40.870374] shmem 0
> [ 40.870566] file_mapped 0
> [ 40.870801] file_dirty 0
> [ 40.871039] file_writeback 0
> [ 40.871292] inactive_anon 0
> [ 40.871542] active_anon 32944128
> [ 40.871821] inactive_file 0
> [ 40.872077] active_file 0
> [ 40.872309] unevictable 0
> [ 40.872543] slab_reclaimable 0
> [ 40.872806] slab_unreclaimable 163840
> [ 40.873136] pgfault 8085
> [ 40.873358] pgmajfault 0
> [ 40.873589] pgrefill 0
> [ 40.873800] pgscan 0
> [ 40.873991] pgsteal 0
> [ 40.874202] pgactivate 0
> [ 40.874424] pgdeactivate 0
> [ 40.874663] pglazyfree 0
> [ 40.874881] pglazyfreed 0
> [ 40.875121] workingset_refault 0
> [ 40.875401] workingset_activate 0
> [ 40.875689] workingset_nodereclaim 0
> [ 40.875996] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
> [ 40.876789] [ 1969] 0 1969 5121 970 86016 0 0 bash
> [ 40.877546] [ 1989] 0 1989 1998 260 61440 0 0 stress
> [ 40.878256] [ 1990] 0 1990 18383 8055 126976 0 0 stress
> [ 40.878955] Memory cgroup out of memory: Kill process 1990 (stress) score 987 or sacrifice child
> [ 40.879803] Killed process 1990 (stress) total-vm:73532kB, anon-rss:32008kB, file-rss:212kB, shmemB
>
> v2: Updated commit message to include an example dump as suggested by
> Roman.
Looks good to me!
I'd still drop the mm events output, but I'm fine with it too.
Acked-by: Roman Gushchin <guro@fb.com>
Thank you!
next prev parent reply other threads:[~2018-08-06 16:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-03 17:57 [PATCH] mm: memcg: update memcg OOM messages on cgroup2 Tejun Heo
2018-08-03 20:30 ` Roman Gushchin
2018-08-06 15:55 ` Johannes Weiner
2018-08-06 15:48 ` Johannes Weiner
2018-08-06 16:15 ` [PATCH v2] " Tejun Heo
2018-08-06 16:34 ` Roman Gushchin [this message]
2018-08-06 18:08 ` Andrew Morton
2018-08-06 18:19 ` Tejun Heo
2018-09-19 17:17 ` Johannes Weiner
2018-08-06 20:06 ` Michal Hocko
2018-08-06 20:19 ` Tejun Heo
2018-08-07 7:13 ` Michal Hocko
2018-08-07 15:09 ` Tejun Heo
2018-08-07 17:54 ` 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=20180806163409.GA19960@castle \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).