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: <20250210220433.24f6c6c7@pumpkin>
Date: Mon, 10 Feb 2025 22:04:33 +0000
From: David Laight <david.laight.linux@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Joel Fernandes
 <joel@...lfernandes.org>, Prakash Sangappa <prakash.sangappa@...cle.com>,
 Peter Zijlstra <peterz@...radead.org>, 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 Mon, 10 Feb 2025 14:43:21 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu, 6 Feb 2025 14:44:08 +0100
> Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> 
> > I did add a scheduling point in rt_spin_unlock() if LAZY was set and
> > based on few tests it was something between noise and worse. It seems
> > that "run to completion" is better than interrupt the kernel in the
> > middle whatever it is doing. "Don't preempt the lock owner" is already
> > handled by LAZY with the scheduling point on return to userland.  
> 
> Does that mean that PREEMPT_RT requires a non preempt method for
> SCHED_OTHER for SCHED_OTHER to not hit the issues that we were originally
> hitting? That is, with being able to preempt spin_locks in PREEMPT_RT,
> running a system with PREEMPT_RT in full preemption mode will still suffer
> performance issues against a non PREEMPT_RT running in full preemption mode?

My 'gut feel' is that all the context switches with PREEMPT_RT add a significant
overhead.
It might not matter if your system is lightly loaded (overspecified),
but if you need to run at 95%+ cpu then they will hit you hard.

Maybe you can afford to drop softint and napi code to a high(ish) priority
thread, but I'd have thought that most interrupts should stay that way and
most spinlocks stay as spinlocks - and probably all disable interrupts!
Any interrupts that take 'a long time' or spinlocks that are held for 'a long time'
really need changing anyway.

But there are some really dreadful bits of code in the kernel.
One of the Intel ethernet drivers spins for ages whenever the bios is accessing
the hardware - you can't run RTP audio tests on that system.

Perhaps interrupt disable and pre-emption times should (optionally) be monitored
and a warning output every time they go up significantly.
A 'name and shame' policy might improve matters.

	David

> 
> -- Steve
>