On Wed, Feb 28, 2024 at 4:22 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > On Tue, Feb 27, 2024 at 09:33:35PM -0800, Namhyung Kim wrote: > > Currently it accounts the contention using delta between timestamps in > > lock:contention_begin and lock:contention_end tracepoints. But it means > > the lock should see the both events during the monitoring period. > > > > Actually there are 4 cases that happen with the monitoring: > > > > monitoring period > > / \ > > | | > > 1: B------+-----------------------+--------E > > 2: B----+-------------E | > > 3: | B-----------+----E > > 4: | B-------------E | > > | | > > t0 t1 > > > > where B and E mean contention BEGIN and END, respectively. So it only > > accounts the case 4 for now. It seems there's no way to handle the case > > 1. The case 2 might be handled if it saved the timestamp (t0), but it > > lacks the information from the B notably the flags which shows the lock > > types. Also it could be a nested lock which it currently ignores. So > > I think we should ignore the case 2. > > Perhaps have a separate output listing locks that were found to be with > at least tE - t0 time, with perhaps a backtrace at that END time? Do you mean long contentions in case 3? I'm not sure what do you mean by tE, but they started after t0 so cannot be greater than or equal to the monitoring period. Maybe we can try with say, 90% of period but we can still miss something. And collecting backtrace of other task would be racy as the it may not contend anymore. > > With that we wouldn't miss that info, however incomplete it is and the > user would try running again, perhaps for a longer time, or start > monitoring before the observed workload starts, etc. Yeah, it can be useful. Let me think about it more. > > Anyway: > > Reviwed-by: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> Thanks for your review! Namhyung
