public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 Juri Lelli <juri.lelli@redhat.com>,
	 Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	 Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,  Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	 linux-kernel@vger.kernel.org
Subject: [patch 2/2] sched/debug: Remove need_resched ratelimiting for warnings
Date: Mon, 6 Jan 2025 12:39:22 -0800 (PST)	[thread overview]
Message-ID: <eeaed106-cb10-3113-030b-ee23ab3ad0c8@google.com> (raw)
In-Reply-To: <77e42990-0ea3-fc53-8051-6856a92ad4d0@google.com>

The need_resched warnings are controlled by two tunables in debugfs:
 - latency_warn_ms
 - latency_warn_once

By default, latency_warn_once is enabled.  Thus, a need_resched warning
is only emitted once per boot.

If the user configures this to not be the case and changes the default,
then allow the user to also control the threshold through latency_warn_ms
that these warnings trigger.  Do not impose our own ratelimiting on top
that may make it appear like there are no cases where need_resched is set
for longer than the threshold.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 kernel/sched/debug.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1293,11 +1293,6 @@ void proc_sched_set_task(struct task_struct *p)
 
 void resched_latency_warn(int cpu, u64 latency)
 {
-	static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1);
-
-	if (likely(!__ratelimit(&latency_check_ratelimit)))
-		return;
-
 	pr_err("sched: CPU %d need_resched set for > %llu ns (%d ticks) without schedule\n",
 	       cpu, latency, cpu_rq(cpu)->ticks_without_resched);
 	dump_stack();

       reply	other threads:[~2025-01-06 20:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <77e42990-0ea3-fc53-8051-6856a92ad4d0@google.com>
2025-01-06 20:39 ` David Rientjes [this message]
2025-01-07 18:14   ` [patch 2/2] sched/debug: Remove need_resched ratelimiting for warnings Madadi Vineeth Reddy
2025-01-07 20:15     ` David Rientjes
2025-01-07 20:45       ` Josh Don
2025-01-09 17:59         ` David Rientjes
2025-01-09 18:53           ` Josh Don
2025-01-10  0:22             ` David Rientjes

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=eeaed106-cb10-3113-030b-ee23ab3ad0c8@google.com \
    --to=rientjes@google.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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