From: Shakeel Butt <shakeelb@google.com>
To: Roman Gushchin <guro@fb.com>
Cc: Richard Palethorpe <rpalethorpe@suse.com>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
LTP List <ltp@lists.linux.it>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Michal Hocko <mhocko@kernel.org>, Tejun Heo <tj@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v4] mm: memcg/slab: Stop reparented obj_cgroups from charging root
Date: Fri, 23 Oct 2020 09:41:48 -0700 [thread overview]
Message-ID: <CALvZod7opFD4RTWmcXP_BHpW=t3uAJQNLx_UKRMw=UtfFA+jSA@mail.gmail.com> (raw)
In-Reply-To: <20201023004026.GG300658@carbon.dhcp.thefacebook.com>
On Thu, Oct 22, 2020 at 5:40 PM Roman Gushchin <guro@fb.com> wrote:
>
> On Thu, Oct 22, 2020 at 04:59:56PM -0700, Shakeel Butt wrote:
> > On Thu, Oct 22, 2020 at 10:25 AM Roman Gushchin <guro@fb.com> wrote:
> > >
> > [snip]
> > > >
> > > > Since bf4f059954dc ("mm: memcg/slab: obj_cgroup API") is in 5.9, I
> > > > think we can take this patch for 5.9 and 5.10 but keep Roman's cleanup
> > > > for 5.11.
> > > >
> > > > What does everyone think?
> > >
> > > I think we should use the link to the root approach both for stable backports
> > > and for 5.11+, to keep them in sync. The cleanup (always charging the root cgroup)
> > > is not directly related to this problem, and we can keep it for 5.11+ only.
> > >
> > > Thanks!
> >
> > Roman, can you send the signed-off patch for the root linking for
> > use_hierarchy=0?
>
> Sure, here we are.
>
> Thanks!
>
> --
>
> From 19d66695f0ef1bf1ef7c51073ab91d67daa91362 Mon Sep 17 00:00:00 2001
> From: Roman Gushchin <guro@fb.com>
> Date: Thu, 22 Oct 2020 17:12:32 -0700
> Subject: [PATCH] mm: memcg: link page counters to root if use_hierarchy is false
>
> Richard reported a warning which can be reproduced by running the LTP
> madvise6 test (cgroup v1 in the non-hierarchical mode should be used):
>
> [ 9.841552] ------------[ cut here ]------------
> [ 9.841788] WARNING: CPU: 0 PID: 12 at mm/page_counter.c:57 page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156)
> [ 9.841982] Modules linked in:
> [ 9.842072] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.9.0-rc7-22-default #77
> [ 9.842266] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812d-rebuilt.opensuse.org 04/01/2014
> [ 9.842571] Workqueue: events drain_local_stock
> [ 9.842750] RIP: 0010:page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156)
> [ 9.842894] Code: 0f c1 45 00 4c 29 e0 48 89 ef 48 89 c3 48 89 c6 e8 2a fe ff ff 48 85 db 78 10 48 8b 6d 28 48 85 ed 75 d8 5b 5d 41 5c 41 5d c3 <0f> 0b eb ec 90 e8 4b f9 88 2a 48 8b 17 48 39 d6 72 41 41 54 49 89
> [ 9.843438] RSP: 0018:ffffb1c18006be28 EFLAGS: 00010086
> [ 9.843585] RAX: ffffffffffffffff RBX: ffffffffffffffff RCX: ffff94803bc2cae0
> [ 9.843806] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff948007d2b248
> [ 9.844026] RBP: ffff948007d2b248 R08: ffff948007c58eb0 R09: ffff948007da05ac
> [ 9.844248] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000001
> [ 9.844477] R13: ffffffffffffffff R14: 0000000000000000 R15: ffff94803bc2cac0
> [ 9.844696] FS: 0000000000000000(0000) GS:ffff94803bc00000(0000) knlGS:0000000000000000
> [ 9.844915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 9.845096] CR2: 00007f0579ee0384 CR3: 000000002cc0a000 CR4: 00000000000006f0
> [ 9.845319] Call Trace:
> [ 9.845429] __memcg_kmem_uncharge (mm/memcontrol.c:3022)
> [ 9.845582] drain_obj_stock (./include/linux/rcupdate.h:689 mm/memcontrol.c:3114)
> [ 9.845684] drain_local_stock (mm/memcontrol.c:2255)
> [ 9.845789] process_one_work (./arch/x86/include/asm/jump_label.h:25 ./include/linux/jump_label.h:200 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2274)
> [ 9.845898] worker_thread (./include/linux/list.h:282 kernel/workqueue.c:2416)
> [ 9.846034] ? process_one_work (kernel/workqueue.c:2358)
> [ 9.846162] kthread (kernel/kthread.c:292)
> [ 9.846271] ? __kthread_bind_mask (kernel/kthread.c:245)
> [ 9.846420] ret_from_fork (arch/x86/entry/entry_64.S:300)
> [ 9.846531] ---[ end trace 8b5647c1eba9d18a ]---
>
> The problem occurs because in the non-hierarchical mode non-root page
> counters are not linked to root page counters, so the charge is not
> propagated to the root memory cgroup.
>
> After the removal of the original memory cgroup and reparenting of the
> object cgroup, the root cgroup might be uncharged by draining a objcg
> stock, for example. It leads to an eventual underflow of the charge
> and triggers a warning.
>
> Fix it by linking all page counters to corresponding root page
> counters in the non-hierarchical mode.
>
> The patch doesn't affect how the hierarchical mode is working,
> which is the only sane and truly supported mode now.
>
> Thanks to Richard for reporting, debugging and providing an
> alternative version of the fix!
>
> Reported-by: ltp@lists.linux.it
> Debugged-by: Richard Palethorpe <rpalethorpe@suse.com>
> Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: stable@vger.kernel.org
Reviewed-by: Shakeel Butt <shakeelb@google.com>
next prev parent reply other threads:[~2020-10-23 16:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 19:07 [RFC PATCH] mm: memcg/slab: Stop reparented obj_cgroups from charging root Richard Palethorpe
2020-10-14 20:08 ` Roman Gushchin
2020-10-16 5:40 ` Richard Palethorpe
2020-10-16 9:47 ` Michal Koutný
2020-10-16 10:41 ` Richard Palethorpe
2020-10-16 15:05 ` Richard Palethorpe
2020-10-16 17:26 ` Michal Koutný
2020-10-16 14:53 ` Johannes Weiner
2020-10-16 17:02 ` Roman Gushchin
2020-10-16 17:15 ` Michal Koutný
2020-10-19 8:45 ` Richard Palethorpe
2020-10-19 9:58 ` [PATCH v3] " Richard Palethorpe
2020-10-19 16:58 ` Shakeel Butt
2020-10-20 5:52 ` Richard Palethorpe
2020-10-20 13:49 ` Richard Palethorpe
2020-10-20 16:56 ` Shakeel Butt
2020-10-21 20:32 ` Roman Gushchin
2020-10-20 17:24 ` Michal Koutný
2020-10-22 7:04 ` Richard Palethorpe
2020-10-22 12:28 ` [PATCH v4] " Richard Palethorpe
2020-10-22 16:37 ` Shakeel Butt
2020-10-22 17:25 ` Roman Gushchin
2020-10-22 23:59 ` Shakeel Butt
2020-10-23 0:40 ` Roman Gushchin
2020-10-23 15:44 ` Johannes Weiner
2020-10-23 16:41 ` Shakeel Butt [this message]
2020-10-26 7:32 ` Richard Palethorpe
2020-10-26 23:14 ` Roman Gushchin
2020-10-19 22:28 ` [RFC PATCH] " Roman Gushchin
2020-10-20 6:04 ` Richard Palethorpe
2020-10-20 12:02 ` Richard Palethorpe
2020-10-20 14:48 ` Richard Palethorpe
2020-10-20 16:27 ` Michal Koutný
2020-10-20 17:07 ` Roman Gushchin
2020-10-20 18:18 ` Johannes Weiner
2020-10-21 19:33 ` Roman Gushchin
2020-10-23 16:30 ` Johannes Weiner
2020-11-10 1:27 ` Roman Gushchin
2020-11-10 15:11 ` Shakeel Butt
2020-11-10 19:13 ` Roman Gushchin
2020-11-20 17:46 ` Michal Koutný
2020-11-03 13:22 ` Michal Hocko
2020-11-03 21:30 ` Roman Gushchin
2020-10-20 16:55 ` Shakeel Butt
2020-10-20 17:17 ` Roman Gushchin
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='CALvZod7opFD4RTWmcXP_BHpW=t3uAJQNLx_UKRMw=UtfFA+jSA@mail.gmail.com' \
--to=shakeelb@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ltp@lists.linux.it \
--cc=mhocko@kernel.org \
--cc=rpalethorpe@suse.com \
--cc=tj@kernel.org \
--cc=vbabka@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;
as well as URLs for NNTP newsgroup(s).