linux-kernel - Re: [PATCH] delayacct/sched: add SOFTIRQ delay

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]

Message-ID: <CAEQmJ=gwOBn5bTY0n1c1c1zu2Gk-peKERCzrW5i+S-4erd7y5Q@mail.gmail.com>
Date: Wed, 20 Aug 2025 16:13:55 +0800
From: Tio Zhang <zyhtheonly@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: akpm@...ux-foundation.org, wang.yaxin@....com.cn, fan.yu9@....com.cn, 
	corbet@....net, bsingharora@...il.com, yang.yang29@....com.cn, 
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, mingo@...hat.com, 
	juri.lelli@...hat.com, vincent.guittot@...aro.org, dietmar.eggemann@....com, 
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com, 
	jiang.kun2@....com.cn, xu.xin16@....com.cn, zyhtheonly@...h.net, 
	张元瀚 Tio Zhang <tiozhang@...iglobal.com>
Subject: Re: [PATCH] delayacct/sched: add SOFTIRQ delay

Peter Zijlstra <peterz@...radead.org> 于2025年8月19日周二 18:14写道：
>
> On Tue, Aug 19, 2025 at 05:27:39PM +0800, Tio Zhang wrote:
> > Intro SOFTIRQ delay, so we can separate softirq as SOFTIRQ delay
> > and hardirq as {IRQ - SOFTIRQ} delay.
> >
> > A typical scenario is when tasks delayed by network,
> > if they delayed by rx net packets, i.e, net_rx_action(),
> > SOFTIRQ delay is almost same as IRQ delay;
> > if they delayed by, e.g, bad driver or broken hardware,
> > SOFTIRQ delay is almost 0 while IRQ delay remains big.
> >
> > Examples tool usage could be found in
> > Documentation/accounting/delay-accounting.rst
>
> accounting will be the death of us :/
>
> How do you account ksoftirqd ?

delay accounting should count delay within the task's own context,
so ksoftirqd should not be take into consideration in "SOFTIRQ delay".

When a task is delayed by ksoftirqd, the task is exactly delayed
by ksoftirqd's preemption, not softirq context:
--------------------------------------------------------------------------------------------
              TASK A
    <runs in A's context>
    <IRQ context>
        | -------------------------------------------------------
        |              counts in A's IRQ delay               |
        | -------------------------------------------------------
    <SOFTIRQ context>
        | -------------------------------------------------------
        |              counts in A's SOFTIRQ delay      |
        | -------------------------------------------------------
     wakeup_softirqd
     preempted by ksoftirqd
     <A in rq waiting>
        | ------------------------------------------------------------------------
        |  counts in A's CPU delay (A->sched_info.run_delay) |
        | ------------------------------------------------------------------------
     ksoftirqd gives the cpu
     <runs in A's context>
--------------------------------------------------------------------------------------------

So when ksoftirqd plays a significant role, we will FISRT see
SOFTIRQ delay increasing in task's delay, THEN see CPU delay
increasing.
We should always find out the task delayed by softirq.

Though not working in PRERMPT_RT (No IRQ delay but always CPU delay).

Btw, I did miss exclude ksoftirqd in irqtime_account_irq, will add in V2.