Re: [PATCH linux-next] delayacct: track delays from IRQ/SOFTIRQ

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 8 Apr 2023 17:28:35 +0800 (CST) <yang.yang29@zte.com.cn> wrote:

> From: Yang Yang <yang.yang19@zte.com.cn>
> 
> 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.