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: <20250206134859.GP7145@noisy.programming.kicks-ass.net>
Date: Thu, 6 Feb 2025 14:48:59 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	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, Feb 06, 2025 at 02:44:08PM +0100, Sebastian Andrzej Siewior wrote:
> SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of
> SCHED_FIFO/ RR/ DL because of this LAZY hint.

Thing will get delayed if interrupts are disabled or kernel has
preemption disabled too. So as long as we ensure hint crap is of equal
order, nothing cares if you do.

If you can't tell the difference between task does hint crap in
userspace and task is in the middle of syscall, you can't tell the
difference.