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@xxxxxxxxxx
