[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250701105653.GO1613376@noisy.programming.kicks-ass.net>
Date: Tue, 1 Jul 2025 12:56:53 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Prakash Sangappa <prakash.sangappa@...cle.com>,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
mathieu.desnoyers@...icios.com, bigeasy@...utronix.de,
kprateek.nayak@....com, vineethr@...ux.ibm.com
Subject: Re: [PATCH V6 1/7] Sched: Scheduler time slice extension
On Tue, Jul 01, 2025 at 10:42:36AM +0200, Thomas Gleixner wrote:
> What's worse is that it breaks the LAZY semantics. I explained this to
> you before and this thing needs to be tied on the LAZY bit otherwise a
> SCHED_OTHER task can prevent a real-time task from running, which is
> fundamentally wrong.
So here we disagree, I don't want this tied to LAZY.
SCHED_OTHER can already inhibit a RT task from getting ran by doing a
syscall, this syscall will have non-preemptible sections and the RT task
will get delayed.
I very much want this thing to be limited to a time frame where a
userspace critical section (this thing) is smaller than such a kernel
critical section.
That is, there should be no observable difference between the effects of
this new thing and a syscall doing preempt_disable().
That said; the reason I don't want this tied to LAZY is that RT itself
is not subject to LAZY and this then means that RT threads cannot make
use of this new facility, whereas I think it makes perfect sense for
them to use this.
Powered by blists - more mailing lists