From: Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Vladimir Davydov
<vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>,
Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
Sergey Senozhatsky
<senozhatsky-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Andy Shevchenko
<andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
Rasmus Villemoes
<linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Mike Rapoport <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>,
Rafael Aquini <aquini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: [PATCH v3 0/4] mm/page_owner: Extend page_owner to show memcg information
Date: Mon, 31 Jan 2022 14:23:04 -0500 [thread overview]
Message-ID: <20220131192308.608837-1-longman@redhat.com> (raw)
v3:
- Add unlikely() to patch 1 and clarify that -1 will not be returned.
- Use a helper function to print out memcg information in patch 3.
- Add a new patch 4 to store task command name in page_owner
structure.
v2:
- Remove the SNPRINTF() macro as suggested by Ira and use scnprintf()
instead to remove some buffer overrun checks.
- Add a patch to optimize vscnprintf with a size parameter of 0.
While debugging the constant increase in percpu memory consumption on
a system that spawned large number of containers, it was found that a
lot of offlined mem_cgroup structures remained in place without being
freed. Further investigation indicated that those mem_cgroup structures
were pinned by some pages.
In order to find out what those pages are, the existing page_owner
debugging tool is extended to show memory cgroup information and whether
those memcgs are offlined or not. With the enhanced page_owner tool,
the following is a typical page that pinned the mem_cgroup structure
in my test case:
Page allocated via order 0, mask 0x1100cca(GFP_HIGHUSER_MOVABLE), pid 162970 (podman), ts 1097761405537 ns, free_ts 1097760838089 ns
PFN 1925700 type Movable Block 3761 type Movable Flags 0x17ffffc00c001c(uptodate|dirty|lru|reclaim|swapbacked|node=0|zone=2|lastcpupid=0x1fffff)
prep_new_page+0xac/0xe0
get_page_from_freelist+0x1327/0x14d0
__alloc_pages+0x191/0x340
alloc_pages_vma+0x84/0x250
shmem_alloc_page+0x3f/0x90
shmem_alloc_and_acct_page+0x76/0x1c0
shmem_getpage_gfp+0x281/0x940
shmem_write_begin+0x36/0xe0
generic_perform_write+0xed/0x1d0
__generic_file_write_iter+0xdc/0x1b0
generic_file_write_iter+0x5d/0xb0
new_sync_write+0x11f/0x1b0
vfs_write+0x1ba/0x2a0
ksys_write+0x59/0xd0
do_syscall_64+0x37/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Charged to offlined memcg libpod-conmon-15e4f9c758422306b73b2dd99f9d50a5ea53cbb16b4a13a2c2308a4253cc0ec8.
So the page was not freed because it was part of a shmem segment. That
is useful information that can help users to diagnose similar problems.
Waiman Long (4):
lib/vsprintf: Avoid redundant work with 0 size
mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check
mm/page_owner: Print memcg information
mm/page_owner: Record task command name
lib/vsprintf.c | 8 +++---
mm/page_owner.c | 69 ++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 59 insertions(+), 18 deletions(-)
--
2.27.0
WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, Ira Weiny <ira.weiny@intel.com>,
Mike Rapoport <rppt@kernel.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <guro@fb.com>, Rafael Aquini <aquini@redhat.com>,
Waiman Long <longman@redhat.com>
Subject: [PATCH v3 0/4] mm/page_owner: Extend page_owner to show memcg information
Date: Mon, 31 Jan 2022 14:23:04 -0500 [thread overview]
Message-ID: <20220131192308.608837-1-longman@redhat.com> (raw)
v3:
- Add unlikely() to patch 1 and clarify that -1 will not be returned.
- Use a helper function to print out memcg information in patch 3.
- Add a new patch 4 to store task command name in page_owner
structure.
v2:
- Remove the SNPRINTF() macro as suggested by Ira and use scnprintf()
instead to remove some buffer overrun checks.
- Add a patch to optimize vscnprintf with a size parameter of 0.
While debugging the constant increase in percpu memory consumption on
a system that spawned large number of containers, it was found that a
lot of offlined mem_cgroup structures remained in place without being
freed. Further investigation indicated that those mem_cgroup structures
were pinned by some pages.
In order to find out what those pages are, the existing page_owner
debugging tool is extended to show memory cgroup information and whether
those memcgs are offlined or not. With the enhanced page_owner tool,
the following is a typical page that pinned the mem_cgroup structure
in my test case:
Page allocated via order 0, mask 0x1100cca(GFP_HIGHUSER_MOVABLE), pid 162970 (podman), ts 1097761405537 ns, free_ts 1097760838089 ns
PFN 1925700 type Movable Block 3761 type Movable Flags 0x17ffffc00c001c(uptodate|dirty|lru|reclaim|swapbacked|node=0|zone=2|lastcpupid=0x1fffff)
prep_new_page+0xac/0xe0
get_page_from_freelist+0x1327/0x14d0
__alloc_pages+0x191/0x340
alloc_pages_vma+0x84/0x250
shmem_alloc_page+0x3f/0x90
shmem_alloc_and_acct_page+0x76/0x1c0
shmem_getpage_gfp+0x281/0x940
shmem_write_begin+0x36/0xe0
generic_perform_write+0xed/0x1d0
__generic_file_write_iter+0xdc/0x1b0
generic_file_write_iter+0x5d/0xb0
new_sync_write+0x11f/0x1b0
vfs_write+0x1ba/0x2a0
ksys_write+0x59/0xd0
do_syscall_64+0x37/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Charged to offlined memcg libpod-conmon-15e4f9c758422306b73b2dd99f9d50a5ea53cbb16b4a13a2c2308a4253cc0ec8.
So the page was not freed because it was part of a shmem segment. That
is useful information that can help users to diagnose similar problems.
Waiman Long (4):
lib/vsprintf: Avoid redundant work with 0 size
mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check
mm/page_owner: Print memcg information
mm/page_owner: Record task command name
lib/vsprintf.c | 8 +++---
mm/page_owner.c | 69 ++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 59 insertions(+), 18 deletions(-)
--
2.27.0
next reply other threads:[~2022-01-31 19:23 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 19:23 Waiman Long [this message]
2022-01-31 19:23 ` [PATCH v3 0/4] mm/page_owner: Extend page_owner to show memcg information Waiman Long
[not found] ` <20220131192308.608837-1-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-01-31 19:23 ` [PATCH v3 1/4] lib/vsprintf: Avoid redundant work with 0 size Waiman Long
2022-01-31 19:23 ` Waiman Long
[not found] ` <20220131192308.608837-2-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-01-31 20:42 ` Mike Rapoport
2022-01-31 20:42 ` Mike Rapoport
2022-01-31 19:23 ` [PATCH v3 2/4] mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check Waiman Long
2022-01-31 19:23 ` Waiman Long
[not found] ` <20220131192308.608837-3-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-01-31 20:38 ` Roman Gushchin
2022-01-31 20:38 ` Roman Gushchin
2022-01-31 20:43 ` Mike Rapoport
2022-01-31 20:43 ` Mike Rapoport
2022-01-31 19:23 ` [PATCH v3 3/4] mm/page_owner: Print memcg information Waiman Long
2022-01-31 19:23 ` Waiman Long
[not found] ` <20220131192308.608837-4-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-01-31 20:51 ` Mike Rapoport
2022-01-31 20:51 ` Mike Rapoport
[not found] ` <YfhLzI+RLRGgexmr-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2022-01-31 21:43 ` Waiman Long
2022-01-31 21:43 ` Waiman Long
[not found] ` <4234fc60-5d65-1089-555a-734218aa6f9c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-01 6:23 ` Mike Rapoport
2022-02-01 6:23 ` Mike Rapoport
2022-01-31 20:51 ` Roman Gushchin
2022-01-31 20:51 ` Roman Gushchin
2022-02-01 10:54 ` Michal Hocko
[not found] ` <YfkRS75D3xcqLT85-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-02-01 17:04 ` Waiman Long
2022-02-01 17:04 ` Waiman Long
[not found] ` <33be132c-874d-1061-9003-50942275b221-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-02 8:49 ` Michal Hocko
2022-02-02 8:49 ` Michal Hocko
[not found] ` <YfpFkVLBb0GsDFsi-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-02-02 16:12 ` Waiman Long
2022-02-02 16:12 ` Waiman Long
2022-01-31 19:23 ` [PATCH v3 4/4] mm/page_owner: Record task command name Waiman Long
2022-01-31 19:23 ` Waiman Long
2022-01-31 22:03 ` [PATCH v4 " Waiman Long
[not found] ` <20220131220328.622162-1-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-01 15:28 ` Michal Hocko
2022-02-01 15:28 ` Michal Hocko
[not found] ` <YflRjeoC0jbzArDG-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-02-02 16:53 ` Waiman Long
2022-02-02 16:53 ` Waiman Long
[not found] ` <4ba66abe-5c6d-26a7-f11c-c3b8514bfb34-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-03 12:10 ` Vlastimil Babka
2022-02-03 12:10 ` Vlastimil Babka
2022-02-03 18:53 ` Waiman Long
2022-02-02 20:30 ` [PATCH v4 0/4] mm/page_owner: Extend page_owner to show memcg information Waiman Long
2022-02-02 23:06 ` Rafael Aquini
2022-02-02 20:30 ` [PATCH v4 2/4] mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check Waiman Long
[not found] ` <20220202203036.744010-3-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-03 15:46 ` Vlastimil Babka
2022-02-03 15:46 ` Vlastimil Babka
[not found] ` <5c03fa31-35a5-4cbc-6b0e-872d5db82a41-AlSwsSmVLrQ@public.gmane.org>
2022-02-03 18:49 ` Waiman Long
2022-02-03 18:49 ` Waiman Long
2022-02-08 10:51 ` Petr Mladek
[not found] ` <20220131192308.608837-5-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-01-31 20:54 ` [PATCH v3 4/4] mm/page_owner: Record task command name Roman Gushchin
2022-01-31 20:54 ` Roman Gushchin
[not found] ` <YfhMd5LTzTHu9zMD-cx5fftMpWqeCjSd+JxjunQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2022-01-31 21:46 ` Waiman Long
2022-01-31 21:46 ` Waiman Long
2022-02-02 20:30 ` [PATCH v4 1/4] lib/vsprintf: Avoid redundant work with 0 size Waiman Long
2022-02-02 20:30 ` Waiman Long
2022-02-08 10:08 ` Petr Mladek
2022-02-02 20:30 ` [PATCH v4 3/4] mm/page_owner: Print memcg information Waiman Long
2022-02-02 20:30 ` Waiman Long
[not found] ` <20220202203036.744010-4-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2022-02-03 6:53 ` Mike Rapoport
2022-02-03 6:53 ` Mike Rapoport
2022-02-03 12:46 ` Michal Hocko
2022-02-03 12:46 ` Michal Hocko
[not found] ` <YfvOp5VXrxy9IW1w-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-02-03 19:03 ` Waiman Long
2022-02-03 19:03 ` Waiman Long
2022-02-07 17:20 ` Michal Hocko
[not found] ` <YgFUxFI5bMbc42j4-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-02-07 19:09 ` Andrew Morton
2022-02-07 19:09 ` Andrew Morton
[not found] ` <20220207110947.f07b58898d91c02090f9aacf-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2022-02-07 19:33 ` Waiman Long
2022-02-07 19:33 ` Waiman Long
2022-02-02 20:30 ` [PATCH v4 4/4] mm/page_owner: Record task command name Waiman Long
2022-02-02 20:30 ` Waiman Long
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=20220131192308.608837-1-longman@redhat.com \
--to=longman-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=aquini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=guro-b10kYP2dOMg@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=pmladek-IBi9RG/b67k@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=senozhatsky-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.