From: Michal Hocko <mhocko@suse.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, hch@lst.de, hannes@cmpxchg.org,
akpm@linux-foundation.org, linux-clk@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-input@vger.kernel.org,
roman.gushchin@linux.dev
Subject: Re: [PATCH v2 8/8] mm: Centralize & improve oom reporting in show_mem.c
Date: Fri, 22 Apr 2022 14:58:19 +0200 [thread overview]
Message-ID: <YmKma/1WUvjjbcO4@dhcp22.suse.cz> (raw)
In-Reply-To: <20220421234837.3629927-14-kent.overstreet@gmail.com>
On Thu 21-04-22 19:48:37, Kent Overstreet wrote:
> This patch:
> - Changes show_mem() to always report on slab usage
> - Instead of reporting on all slabs, we only report on top 10 slabs,
> and in sorted order
As I've already pointed out in the email thread for the previous
version, this would be better in its own patch explaining why we want to
make this unconditional and why to limit the number caches to print.
Why the trashold shouldn't be absolute size based?
> - Also reports on shrinkers, with the new shrinkers_to_text().
> Shrinkers need to be included in OOM/allocation failure reporting
> because they're responsible for memory reclaim - if a shrinker isn't
> giving up its memory, we need to know which one and why.
Again, I do agree that information about shrinkers can be useful but
there are two main things to consider. Do we want to dump that
information unconditionaly? E.g. does it make sense to print for all
allocation requests (even high order, GFP_NOWAIT...)? Should there be
any explicit trigger when to dump this data (like too many shrinkers
failing etc)?
Last but not least let me echo the concern from the other reply. Memory
allocations are not really reasonable to be done from the oom context so
the pr_buf doesn't sound like a good tool here.
Also please make sure to provide an example of the output and _explain_
how the new output is better than the existing one.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-04-22 12:58 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 23:48 [PATCH 0/4] Printbufs & shrinker OOM reporting Kent Overstreet
2022-04-21 23:48 ` [PATCH 1/4] lib/printbuf: New data structure for heap-allocated strings Kent Overstreet
2022-04-21 23:48 ` [PATCH 2/4] mm: Add a .to_text() method for shrinkers Kent Overstreet
2022-04-22 12:21 ` Michal Hocko
2022-04-21 23:48 ` [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c Kent Overstreet
2022-04-21 23:48 ` [PATCH 4/4] bcachefs: shrinker.to_text() methods Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 0/8] Printbufs & improved shrinker debugging Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 1/8] lib/printbuf: New data structure for heap-allocated strings Kent Overstreet
2022-04-22 4:20 ` Christoph Hellwig
2022-04-22 5:14 ` Kent Overstreet
2022-04-22 5:22 ` Christoph Hellwig
2022-04-22 5:40 ` Kent Overstreet
2022-04-22 5:52 ` Christoph Hellwig
2022-04-22 6:06 ` Kent Overstreet
2022-04-22 6:11 ` Christoph Hellwig
2022-04-22 6:18 ` Kent Overstreet
2022-04-22 15:37 ` Steven Rostedt
2022-04-22 19:30 ` Kent Overstreet
2022-04-22 19:39 ` Steven Rostedt
2022-04-22 20:30 ` Kent Overstreet
2022-04-22 20:47 ` Steven Rostedt
2022-04-22 21:51 ` Kent Overstreet
2022-04-22 22:20 ` Steven Rostedt
2022-04-22 20:03 ` James Bottomley
2022-04-22 21:13 ` Kent Overstreet
2022-04-23 14:16 ` Rust and Kernel Vendoring [Was Re: [PATCH v2 1/8] lib/printbuf: New data structure for heap-allocated strings] James Bottomley
2022-04-24 20:36 ` Kent Overstreet
2022-04-26 2:22 ` James Bottomley
2022-04-24 23:46 ` [PATCH v2 1/8] lib/printbuf: New data structure for heap-allocated strings Joe Perches
2022-04-25 0:45 ` Kent Overstreet
2022-04-25 2:44 ` Matthew Wilcox
2022-04-25 4:19 ` Kent Overstreet
2022-04-25 4:48 ` Joe Perches
2022-04-25 4:59 ` Kent Overstreet
2022-04-25 5:00 ` Joe Perches
2022-04-25 5:56 ` Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 2/8] Input/joystick/analog: Convert from seq_buf -> printbuf Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 3/8] mm/memcontrol.c: Convert to printbuf Kent Overstreet
2022-04-22 12:28 ` Michal Hocko
2022-04-21 23:48 ` [PATCH v2 4/8] clk: tegra: bpmp: " Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 5/8] mm: Add a .to_text() method for shrinkers Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 6/8] mm: Count requests to free & nr freed per shrinker Kent Overstreet
2022-04-21 23:48 ` [PATCH v2 7/8] mm: Move lib/show_mem.c to mm/ Kent Overstreet
2022-04-22 12:32 ` Michal Hocko
2022-04-21 23:48 ` [PATCH v2 8/8] mm: Centralize & improve oom reporting in show_mem.c Kent Overstreet
2022-04-22 12:58 ` Michal Hocko [this message]
2022-04-22 15:09 ` Roman Gushchin
2022-04-22 23:48 ` Kent Overstreet
2022-04-23 0:27 ` Roman Gushchin
2022-04-23 0:46 ` Kent Overstreet
2022-04-23 1:25 ` Roman Gushchin
2022-04-23 11:48 ` Tetsuo Handa
2022-04-25 9:28 ` Michal Hocko
2022-04-25 15:28 ` Kent Overstreet
2022-04-26 7:17 ` Michal Hocko
2022-04-26 7:26 ` Kent Overstreet
2022-04-26 7:40 ` Michal Hocko
2022-04-30 4:00 ` [PATCH 0/4] Printbufs & shrinker OOM reporting Dave Young
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=YmKma/1WUvjjbcO4@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=kent.overstreet@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-tegra@vger.kernel.org \
--cc=roman.gushchin@linux.dev \
/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