[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251202082206.EnnTU37J@linutronix.de>
Date: Tue, 2 Dec 2025 09:22:06 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Jan Kiszka <jan.kiszka@...mens.com>
Cc: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
stable-rt <stable-rt@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Davidlohr Bueso <dave@...olabs.net>,
Frederic Weisbecker <frederic@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Thomas Gleixner <tglx@...utronix.de>,
Florian Bezdeka <florian.bezdeka@...mens.com>,
Pavel Machek <pavel@...x.de>
Subject: Re: [PATCH v3 3/3] softirq: Use a dedicated thread for timer wakeups
on PREEMPT_RT.
On 2025-12-02 07:57:04 [+0100], Jan Kiszka wrote:
> So, we have this right now in the 6.12-rt and 6.1-rt trees. The patch
> (b12e35832805) that enabled the lockup above was added to 4.18. In
> 4.19-rt (still under maintenance via 4.19-cip-rt), we had ktimersoftd -
> was that addressing the issue as well? Or could timers have expired back
> then also outside of that thread, thus potentially without SCHED_FIFO prio?
Looking at v4.19.25-rt16, there is ktimersoftd/ via "softirq: split
timer softirqs out of ksoftirqd". This became later ktimers/.
So yes, the timer should be expired with a SCHED_FIFO priority.
You are most likely aware of "Defer throttle when task exits to user"
https://lore.kernel.org/all/20250829081120.806-1-ziqianlu@bytedance.com/
> Thanks,
> Jan
Sebastian
Powered by blists - more mailing lists