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: <20250205081019.6f81f05a@gandalf.local.home>
Date: Wed, 5 Feb 2025 08:10:19 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: 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, 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@...cle.com, konrad.wilk@...cle.com, jgross@...e.com,
 andrew.cooper3@...rix.com, Joel Fernandes <joel@...lfernandes.org>, 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>, bigeasy@...utronix.de, daniel.wagner@...e.com,
 joseph.salisbury@...cle.com, broonie@...il.com
Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

On Wed, 5 Feb 2025 10:07:36 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> > This is where we will disagree for the reasons I explained in my second
> > email. This feature affects other tasks. And no, making it 20us doesn't
> > make it better. Because from what I get from you, if we implement this, it
> > will be available for all preemption methods (including PREEMPT_RT), where
> > we do have less than 50us latency, and and even a 20us will break those
> > applications.  
> 
> Then pick another number; RT too has a max scheduling latency number (on
> some random hardware). If you stay below that, all is fine. 

So we set it to 1us?

Or does this have to calculate what that latency number is for each random
hardware?

> 
> > This was supposed to be only a hint to the kernel, not a complete feature  
> 
> That's a contradiction in terms -- even a hint is a feature.

Yes, a hint is a feature, I meant "complete feature" meaning it being not
just a hint, but guaranteed to do something.

> 
> > that is hard coded and will override how other tasks behave.   
> 
> Everything has some effect. My point is that if you limit this effect to
> be less than what it can already effect, you're not making things worse.
> 
> > As system
> > calls themselves can make how things are scheduled depending on the
> > preemption method,  
> 
> What?

Read my last email:

  https://lore.kernel.org/all/20250204100555.1a641b9b@gandalf.local.home/

I went into this in detail.


> 
> > I didn't want to add something that will change how
> > things are scheduled that ignores the preemption method that was chosen.  
> 
> Userspace is totally oblivious to the preemption method chosen, and it
> damn well should be.

Agreed, and user space doesn't have to know what preemption method was
chosen for this. Where does this say that it needs to know?

All this does is to give the kernel a hint that it is in a critical section
and the kernel decides to grant some more time or not.

The preemption method will influence that decision, but user space doesn't
need to be know.

-- Steve