On Thu, Mar 28, 2024 at 12:23:52PM -0700, Andrew Morton wrote: > On Thu, 28 Mar 2024 15:15:03 -0400 Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > On Wed, Mar 27, 2024 at 10:40:10AM -0700, Andrew Morton wrote: > > > On Wed, 27 Mar 2024 23:57:45 +0800 Kemeng Shi <shikemeng@xxxxxxxxxxxxxxx> wrote: > > > > > > > This series tries to improve visilibity of writeback. > > > > > > Well... why? Is anyone usefully using the existing instrumentation? > > > What is to be gained by expanding it further? What is the case for > > > adding this code? > > > > > > I don't recall hearing of anyone using the existing debug > > > instrumentation so perhaps we should remove it! > > > > Remove debug instrumentation!? Surely you just? > > Absolutely not. Any code in the kernel should have ongoing > justification for remaining there. If no such justification exists, > out it goes. Certainly, but this isn't remotely a case where I'd expect to be getting that kind of feedback. Debugging instrumentation is very much a case where no one notices it 99% of the time, but when you need it you _really_ need it. Not having it can turn a 10 minute "oh, that thing is acting wonky - it's because your system is overloaded/your drive is wonky/x subsystem sucks, we know about it and we're working on it" into a weeklong bughunt, burning up expensive engineer time pointlessly. To debug complex systems efficiently, in production, in the wild, we need to be able to see what's going on - we need more of this stuff. Not to say that this couldn't use more work - perhaps additional focus on what kinds of issues we expect to need to debug with this, what the numbers mean and are useful for, documentation on how this relates to writeback internals, etc.
