On Sat, 8 Apr 2023 17:28:35 +0800 (CST) <yang.yang29@xxxxxxxxxx> wrote: > From: Yang Yang <yang.yang19@xxxxxxxxxx> > > Delay accounting does not track the delay of IRQ/SOFTIRQ. While > IRQ/SOFTIRQ could have obvious impact on some workloads productivity, > such as when workloads are running on system which is busy handling > network IRQ/SOFTIRQ. > > Get the delay of IRQ/SOFTIRQ could help users to reduce such delay. > Such as setting interrupt affinity or task affinity, using kernel thread for > NAPI etc. This is inspired by "sched/psi: Add PSI_IRQ to track IRQ/SOFTIRQ > pressure"[1]. Also fix some code indent problems of older code. > > And update tools/accounting/getdelays.c: > / # ./getdelays -p 156 -di > print delayacct stats ON > printing IO accounting > PID 156 > > CPU count real total virtual total delay total delay average > 15 15836008 16218149 275700790 18.380ms > IO count delay total delay average > 0 0 0.000ms > SWAP count delay total delay average > 0 0 0.000ms > RECLAIM count delay total delay average > 0 0 0.000ms > THRASHING count delay total delay average > 0 0 0.000ms > COMPACT count delay total delay average > 0 0 0.000ms > WPCOPY count delay total delay average > 36 7586118 0.211ms > IRQ count delay total delay average > 42 929161 0.022ms Seems sensible. I'm not sure who's the best person to review/ack this nowadays. We're somewhat double-accounting. Delays due to, for example, IO will already include delays from IRQ activity. But it's presumably a minor thing and I don't see why anyone would care.
