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: <20250206095709.7a93ac36@gandalf.local.home>
Date: Thu, 6 Feb 2025 09:57:09 -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 15:27:17 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> I'm assuming you have a recent number around -- what's sane? 5us, less?

It really doesn't matter what the number is. No matter what it is, it adds
to the latency.

Just adding the timer and another interrupt just doubled the interrupt
latency. If an RT task were to wake up but this flag is set to extend the
currently running task, even if you made it 5us, it will be more than that.
You need to enable a new timer, get back to user space, trigger another
interrupt, before you can schedule the RT task from its original time it
was to wake up and run.

-- Steve