From: Kent Overstreet <kent.overstreet@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, roman.gushchin@linux.dev,
hannes@cmpxchg.org
Subject: Re: [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c
Date: Fri, 22 Apr 2022 05:44:13 -0400 [thread overview]
Message-ID: <20220422094413.2i6dygfpul3toyqr@moria.home.lan> (raw)
In-Reply-To: <YmJ06cEyX2u4DGtD@dhcp22.suse.cz>
On Fri, Apr 22, 2022 at 11:27:05AM +0200, Michal Hocko wrote:
> We already do that in some form. We dump unreclaimable slabs if they
> consume more memory than user pages on LRUs. We also dump all slab
> caches with some objects. Why is this approach not good? Should we tweak
> the condition to dump or should we limit the dump? These are reasonable
> questions to ask. Your patch has dropped those without explaining any
> of the motivation.
>
> I am perfectly OK to modify should_dump_unreclaim_slab to dump even if
> the slab memory consumption is lower. Also dumping small caches with
> handful of objects can be excessive.
>
> Wrt to shrinkers I really do not know what kind of shrinkers data would
> be useful to dump and when. Therefore I am asking about examples.
Look, I've given you the sample output you asked for and explained repeatedly my
rationale and you haven't directly responded; if you have a reason you're
against the patches please say so, but please give your reasoning.
next prev parent reply other threads:[~2022-04-22 9:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 20:31 [PATCH 0/4] Printbufs & shrinker OOM reporting Kent Overstreet
2022-04-19 20:31 ` [PATCH 1/4] lib/printbuf: New data structure for heap-allocated strings Kent Overstreet
2022-04-19 21:11 ` Matthew Wilcox
2022-04-20 0:12 ` Kent Overstreet
2022-04-20 5:02 ` Christoph Hellwig
2022-04-20 5:18 ` Kent Overstreet
2022-04-19 20:32 ` [PATCH 2/4] mm: Add a .to_text() method for shrinkers Kent Overstreet
2022-04-19 20:32 ` [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c Kent Overstreet
2022-04-20 6:58 ` Michal Hocko
2022-04-20 16:58 ` Kent Overstreet
2022-04-21 9:18 ` Michal Hocko
2022-04-21 18:42 ` Kent Overstreet
2022-04-22 8:03 ` Michal Hocko
2022-04-22 8:30 ` Kent Overstreet
2022-04-22 9:27 ` Michal Hocko
2022-04-22 9:44 ` Kent Overstreet [this message]
2022-04-22 10:51 ` Michal Hocko
2022-04-22 10:58 ` Kent Overstreet
2022-04-19 20:32 ` [PATCH 4/4] bcachefs: shrinker.to_text() methods Kent Overstreet
2022-04-21 23:48 [PATCH 0/4] Printbufs & shrinker OOM reporting Kent Overstreet
2022-04-21 23:48 ` [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c Kent Overstreet
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=20220422094413.2i6dygfpul3toyqr@moria.home.lan \
--to=kent.overstreet@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--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 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.