linux-kernel - Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

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: <20250206092041.3fe52ff5@gandalf.local.home>
Date: Thu, 6 Feb 2025 09:20:41 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Joel Fernandes
 <joel@...lfernandes.org>, Prakash Sangappa <prakash.sangappa@...cle.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Thomas
 Gleixner <tglx@...utronix.de>, Ankur Arora <ankur.a.arora@...cle.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
 x86@...nel.org, Andrew Morton <akpm@...ux-foundation.org>, luto@...nel.org,
 bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
 juri.lelli@...hat.com, vincent.guittot@...aro.org, willy@...radead.org,
 mgorman@...e.de, jon.grimm@....com, bharata@....com,
 raghavendra.kt@....com, Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 Konrad Wilk <konrad.wilk@...cle.com>, jgross@...e.com,
 Andrew.Cooper3@...rix.com, Vineeth Pillai <vineethrp@...gle.com>, Suleiman
 Souhlal <suleiman@...gle.com>, Ingo Molnar <mingo@...nel.org>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Clark Williams
 <clark.williams@...il.com>, daniel.wagner@...e.com, Joseph Salisbury
 <joseph.salisbury@...cle.com>, broonie@...il.com
Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

On Thu, 6 Feb 2025 14:57:44 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> Right, but so what? Same delay will happen if interrupt fires in the
> middle of a preempt_disable() region.
> 
> Or if interrupt gets pending while interrupts are disabled, except your
> trace will not show that.
> 
> Your worst case response time isn't affected. That's all that matters.

So now if a task has this set, and an interrupt goes off and wakes an RT
task, not only is the time of the interrupt the latency of the RT task, but
also this extension of the SCHED_OTHER task.

That is, where it use to be:

             event   RT task scheduled
               |      |
               v      v
 time: |-------+-+----+--
                 ^
                 |
             interrupt

If the interrupt triggered just as the task set this bit, we then have:

             event   set Xus    RT task scheduled
               |      |          |
               v      v          v
 time: |-------+-+----+-------+--+
                 ^            ^
                 |            |
             interrupt    Xus timer triggered


This adds on *top* of the current latency, and is not just by itself.

Yes, this may not happen often, but in RT we very much do care about the
worst case scenarios. (That's the difference between an RT project and a
project that just uses RT).

-- Steve