On Fri, Dec 08, 2023 at 05:44:16PM -0800, Roman Gushchin wrote: > On Wed, Dec 06, 2023 at 02:13:49PM -0500, Kent Overstreet wrote: > 0;95;0c> On Wed, Dec 06, 2023 at 07:16:04PM +1100, Dave Chinner wrote: > > > On Fri, Dec 01, 2023 at 12:01:33PM -0800, Roman Gushchin wrote: > > > > What would be the proper solution to this problem from your point of view? > > > > What functionality/API mm can provide to make the life of fs developers > > > > better here? > > > > > > What can we do better? > > > > > > The first thing we can do better that comes to mind is to merge > > > Kent's patches that allow the shrinker owner to output debug > > > information when requested by the infrastructure. > > > > > > Then we - the shrinker implementers - have some control of our own > > > destiny. We can add whatever we need to solve shrinker and OOM > > > problems realted to our shrinkers not doing the right thing. > > > > > > But without that callout from the infrastructure and the > > > infrastructure to drive it at appropriate times, we will make zero > > > progress improving the situation. > > > > > > Yes, the code may not be perfect and, yes, it may not be useful to > > > mm developers, but for the people who have to debug shrinker related > > > problems in production systems we need all the help we can get. We > > > certainly don't care if it isn't perfect, just having something we > > > can partially tailor to our iindividual needs is far, far better > > > than the current situation of nothing at all... > > > > Of course if mm people don't want it I've got better things to do than > > fight uphill battles just to get some reviewed-by tags. Real high > > quality review feedback in this thread. > > (ignoring an attack towards all mm people, sigh) > > Kent, I think extending the shrinker debugfs interface is useful. > And in this context there is no need to limit the output to 10 items. > Also most of disagreements will vanish (sorry, if I missed something, > but looks like all concerns are related to the oom part). > Will it work for you? > > If yes, would you be able to drop the oom part (at least for now) > and resend the patchset? No: OOM debugging is the entire point of the patchset.
