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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Apr 2023 21:31:29 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     <yang.yang29@....com.cn>
Cc:     <bsingharora@...il.com>, <mingo@...hat.com>, <corbet@....net>,
        <juri.lelli@...hat.com>, <linux-fsdevel@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-doc@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH linux-next] delayacct: track delays
 from IRQ/SOFTIRQ

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

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