linux-kernel - Re: [PATCH V6 1/1] Softirq:avoid large sched delay from the pending softirqs

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>] [day] [month] [year] [list]

Message-ID: <20200914114110.esjlzcukfx5emkke@e107158-lin.cambridge.arm.com>
Date:   Mon, 14 Sep 2020 12:41:11 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     John Dias <joaodias@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, qianjun.kernel@...il.com,
        tglx@...utronix.de, will@...nel.org, luto@...nel.org,
        LKML <linux-kernel@...r.kernel.org>, laoar.shao@...il.com,
        urezki@...il.com, Wei Wang <wvw@...gle.com>,
        Quentin Perret <qperret@...gle.com>
Subject: Re: [PATCH V6 1/1] Softirq:avoid large sched delay from the pending
 softirqs

On 09/11/20 12:14, John Dias wrote:
> I agree that the rt-softirq interaction patches are a gross hack (and I
> wrote the original versions, so it's my grossness). The problem is that
> even a 1ms delay in executing those low-latency audio threads is enough to
> cause obvious glitching in audio under very real circumstances, which is
> not an acceptable user experience -- and some softirq handlers run for >1ms
> on their own. (And 1ms is a high upper bound, not a median target.)

AFAIK professional audio apps have the toughest limit of sub 10ms. 120MHz
screens impose a stricter limit on display pipeline too to finish its frame in
8ms.

1ms is too short and approaches PREEMPT_RT realm.

Is it possible to expand on the use case here? What application requires this
constraint?

Thanks

--
Qais Yousef