On Thu, Mar 28, 2024 at 09:31:57AM -1000, Tejun Heo wrote: > Hello, Kent. > > On Thu, Mar 28, 2024 at 03:24:35PM -0400, Kent Overstreet wrote: > > fs/bcachefs/time_stats.c has some code that's going to be moving out to > > lib/ at some point, after I switch it to MAD; if you could hook that up > > as well to a few points we could see at a glance if there are stalls > > happening in the writeback path. > > Using BPF (whether through bcc or bpftrace) is likely a better approach for > this sort of detailed instrumentation. Fixed debug information is useful and > it's also a common occurrence that they don't quite reveal the full picture > of what one's trying to understand and one needs to dig a bit deeper, wider, > aggregate data in a different way, or whatever. > > So, rather than adding more fixed infrastructure, I'd suggest adding places > which can easily be instrumented using the existing tools (they are really > great once you get used to them) whether that's tracepoints or just > strategically placed noinline functions. Collecting latency numbers at various key places is _enormously_ useful. The hard part is deciding where it's useful to collect; that requires intimate knowledge of the code. Once you're defining those collection poitns statically, doing it with BPF is just another useless layer of indirection. The time stats stuff I wrote is _really_ cheap, and you really want this stuff always on so that you've actually got the data you need when you're bughunting.
