From: Dave Chinner <dchinner@redhat.com>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Yang Shi <shy828301@gmail.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
Hillf Danton <hdanton@sina.com>
Subject: Re: [PATCH v2 0/7] mm: introduce shrinker debugfs interface
Date: Wed, 27 Apr 2022 11:22:55 +1000 [thread overview]
Message-ID: <Ymia75Bh/sn/FQdV@rh> (raw)
In-Reply-To: <Ymggvr4Boc5JIf9j@carbon>
On Tue, Apr 26, 2022 at 09:41:34AM -0700, Roman Gushchin wrote:
> Can you, please, summarize your position, because it's a bit unclear.
> You made a lot of good points about some details (e.g. shrinkers naming,
> and I totally agree there; machines with hundreds of nodes etc), then
> you said the active scanning is useless and then said the whole thing
> is useless and we're fine with what we have regarding shrinkers debugging.
Better introspection the first thing we need. Work on improving
that. I've been making suggestions to help improve introspection
infrastructure.
Before anything else, we need to improve introspection so we can
gain better insight into the problems we have. Once we understand
the problems better and have evidence to back up where the problems
lie and we have a plan to solve them, then we can talk about whether
we need other user accessible shrinker APIs.
For the moment, exposing shrinker control interfaces to userspace
could potentially be very bad because it exposes internal
architectural and implementation details to a user API. Just
because it is in /sys/kernel/debug it doesn't mean applications
won't start to use it and build dependencies on it.
That doesn't mean I'm opposed to exposing a shrinker control
mechanism to debugfs - I'm still on the fence on that one. However,
I definitely think that an API that directly exposes the internal
implementation to userspace is the wrong way to go about this.
Fine grained shrinker control is not necessary to improve shrinker
introspection and OOM debugging capability, so if you want/need
control interfaces then I think you should separate those out into a
separate line of development where it doesn't derail the discussion
on how to improve shrinker/OOM introspection.
-Dave.
--
Dave Chinner
dchinner@redhat.com
next prev parent reply other threads:[~2022-04-27 1:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 20:26 [PATCH v2 0/7] mm: introduce shrinker debugfs interface Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 1/7] mm: introduce debugfs interface for kernel memory shrinkers Roman Gushchin
2022-04-23 7:51 ` Christophe JAILLET
2022-04-23 7:51 ` Christophe JAILLET
2022-04-22 20:26 ` [PATCH v2 2/7] mm: memcontrol: introduce mem_cgroup_ino() and mem_cgroup_get_from_ino() Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 3/7] mm: introduce memcg interfaces for shrinker debugfs Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 4/7] mm: introduce numa " Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 5/7] mm: provide shrinkers with names Roman Gushchin
2022-04-23 7:46 ` Christophe JAILLET
2022-04-23 7:46 ` Christophe JAILLET
2022-04-28 0:25 ` Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 6/7] docs: document shrinker debugfs Roman Gushchin
2022-04-22 20:26 ` [PATCH v2 7/7] tools: add memcg_shrinker.py Roman Gushchin
[not found] ` <20220423003552.2914-1-hdanton@sina.com>
2022-04-23 1:29 ` [PATCH v2 3/7] mm: introduce memcg interfaces for shrinker debugfs Roman Gushchin
2022-04-26 6:02 ` [PATCH v2 0/7] mm: introduce shrinker debugfs interface Dave Chinner
2022-04-26 6:45 ` Kent Overstreet
2022-04-26 16:41 ` Roman Gushchin
2022-04-26 18:37 ` Kent Overstreet
2022-04-27 1:22 ` Dave Chinner [this message]
2022-04-27 2:18 ` Roman Gushchin
2022-04-26 19:05 ` Roman Gushchin
2022-04-27 1:02 ` Dave Chinner
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=Ymia75Bh/sn/FQdV@rh \
--to=dchinner@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hdanton@sina.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=roman.gushchin@linux.dev \
--cc=shy828301@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).