public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: wen.yang@linux.dev
To: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: Wen Yang <wen.yang@linux.dev>, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] sched: expose RT throttling info to facilitate priority reversal processing
Date: Tue,  2 Dec 2025 13:51:17 +0800	[thread overview]
Message-ID: <cover.1764648076.git.wen.yang@linux.dev> (raw)

From: Wen Yang <wen.yang@linux.dev>

This series helps to solve a priority reversal issue, where a CFS task
waits for an rtmutex lock, an RT task holding the lock stops due to
RT throttling, and higher priority RT tasks frequently trigger RT
throttling due to long-term CPU consumption.

Details of it:

A priority inversion scenario can occur when a CFS task is starved
due to RT throttling. The scenario is as follows:

0. An rtmutex (e.g., softirq_ctrl.lock) is contended by both CFS
   tasks (e.g., ksoftirqd) and RT tasks (e.g., ktimer).
1. An RT task 'A' (e.g., ktimer) acquired the rtmutex.
2. A CFS task 'B' (e.g., ksoftirqd) attempts to acquire the same
   rtmutex and blocks.
3. A higher-priority RT task 'C' (e.g., stress-ng) runs for an
   extended period, preempting task 'A' and causing the RT runqueue
   to be throttled.
4. Once throttled, CFS task 'B' should run, but it remains blocked
   because the lock is still held by the non-running RT task 'A'. This
   can even lead to the CPU going idle.
5. When the throttle period ends, the high-priority RT task 'C'
   resumes execution, and the cycle repeats, leading to indefinite
   starvation of CFS task 'B'.

A typical stack trace for the blocked ksoftirqd shows it in a 'D'
(TASK_RTLOCK_WAIT) state, waiting on the lock:
     ksoftirqd/5-61      [005] d...211 58212.064160: sched_switch: prev_comm=ksoftirqd/5 prev_pid=61 prev_prio=120 prev_state=D ==> next_comm=swapper/5 next_pid=0 next_prio=120
     ksoftirqd/5-61      [005] d...211 58212.064161: <stack trace>
 => __schedule
 => schedule_rtlock
 => rtlock_slowlock_locked
 => rt_spin_lock
 => __local_bh_disable_ip
 => run_ksoftirqd
 => smpboot_thread_fn
 => kthread
 => ret_from_fork

These two patches expose the TASK_RTLOCK_WAIT state and add
throttle_count to rt_rq for monitoring in /proc/sched_debug.

User-space tools like stalld can use this info to detect and resolve
the inversion, for example, by boosting the lock holder or adjusting 
the priority of the blocked CFS task in TASK_RTLOCK_WAIT state.

Wen Yang (2):
  sched/debug: add explicit TASK_RTLOCK_WAIT printing
  sched/rt: add RT throttle statistics

 fs/proc/array.c              |  3 ++-
 include/linux/sched.h        | 21 +++++++++------------
 include/trace/events/sched.h |  1 +
 kernel/sched/debug.c         |  1 +
 kernel/sched/rt.c            |  1 +
 kernel/sched/sched.h         |  1 +
 6 files changed, 15 insertions(+), 13 deletions(-)

Cc: linux-kernel@vger.kernel.org
-- 
2.25.1


             reply	other threads:[~2025-12-02  5:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  5:51 wen.yang [this message]
2025-12-02  5:51 ` [PATCH 1/2] sched/debug: add explicit TASK_RTLOCK_WAIT printing wen.yang
2025-12-02  5:51 ` [PATCH 2/2] sched/rt: add RT throttle statistics wen.yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1764648076.git.wen.yang@linux.dev \
    --to=wen.yang@linux.dev \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox