diff options
| author | Breno Leitao <leitao@debian.org> | 2026-08-10 04:29:25 -0700 |
|---|---|---|
| committer | Paul E. McKenney <paulmck@kernel.org> | 2026-08-23 17:01:46 -0700 |
| commit | 38308bbd9f164873eb9bbd431ebafbc7fd783e9b (patch) | |
| tree | 301ad2f90ae0060b77ed4da88175d9ff79d36696 /scripts | |
| parent | 07230d21630f48e74831efda665a3200c645e9c2 (diff) | |
| download | linux-next-38308bbd9f164873eb9bbd431ebafbc7fd783e9b.tar.gz linux-next-38308bbd9f164873eb9bbd431ebafbc7fd783e9b.zip | |
locking/csd-lock: Report how long a stuck CSD lock took to recover
The CSD lock debug output is a useful way to catch IPI stalls, but when
the lock finally recovers it only says that it did:
smp: csd: CSD lock (#1) got unstuck on CPU#32, CPU#123 released the lock.
How long the target took to answer is left out, even though
csd_lock_wait_toolong() already has the timestamp the wait started from.
At Meta's fleet, that line fired 211K times in the last 24 hours, so
plenty of stalls get reported with no indication of how long they
lasted.
Print how long the lock was stuck, and, when an IPI was re-sent, how
long after that re-send the target released, as:
smp: csd: CSD lock (#1) got unstuck on CPU#00, CPU#01 released the lock after 8000854660 ns, 3000825778 ns after the last IPI re-send.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions