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: <20250206134408.lD_POjuG@linutronix.de>
Date: Thu, 6 Feb 2025 14:44:08 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: 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 2025-02-06 08:30:39 [-0500], Steven Rostedt wrote:
>   NEED_RESCHED_LAZY was introduced to remedy this. It would be set for
>   SCHED_OTHER tasks and NEED_RESCHED for RT tasks. If the task was holding
>   a sleeping spin lock, the NEED_RESCHED_LAZY would not preempt the running
>   task, but NEED_RESCHED would. If the SCHED_OTHER task was not holding a
>   sleeping spin_lock it would be preempted regardless.
> 
> This improved the performance of SCHED_OTHER tasks in PREEMPT_RT to be as
> good as what was in vanilla.
> 
> You see, LAZY was *created* for this purpose. Of letting the scheduler know
> that the running task is in a critical section and the timer tick should
> not preempt a SCHED_OTHER task.

This was introduced that way originally. It helped because we did not
preempt lock-owner unless we had to. This isn't the case with LAZY
as of today.
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.

> I just wanted to extend this to SCHED_OTHER in user space too.
> 
> > 
> > Yes, I have worked on RT projects before --  you would know better
> > than anyone. :-D. But admittedly, I haven't got to work much with
> > PREEMPT_RT systems.
> 
> Just using RT policy to improve performance is not an RT project. I'm
> talking about projects that if you miss a deadline things crash. Where the
> project works very hard to make sure everything works as intended.
> 
> I'm totally against allowing SCHED_OTHER to use any feature that can delay
> an RT/DL task (unless of course it is to help those, like priority inheritance).
> 
> There's several RT folks on this thread. I wonder if any of
> them are OK with this?

If you roll your own (sched_ext) then do what you want as per you
sched-policy.
If you use this LAZY bit as a hint from userland to kernel as "please
give me up to X usec/ ticks before cutting me off" fine. It is
SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of
SCHED_FIFO/ RR/ DL because of this LAZY hint.

> -- Steve

Sebastian