From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CD671F37DA for ; Tue, 7 Jan 2025 18:15:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736273718; cv=none; b=anQRDRNRrNRZKAuYCx35bcZMgzWzJLUQURVKfL2oDPMZzjavNfbUsKg0Ca9qFhKfySs5bZETeX00+TdJ9WCIiq4Fg2Cu8AcAhJebyW4Fxtz5neq3I/8OO8dobUGSwqgEPKyt03ou8rOvnPfpcOvG1FwI8z+/nDUotZwuPpwtdTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736273718; c=relaxed/simple; bh=bVSmP5Z0+EUtyNdizZo787MyWT9T9okzjImGbPx9mdk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MZU62IsI3fTnay37CQLkxSLYlnSmUlKCNhhkPgxWNQyB872MWtU9t0HdQ3/7ajEeQwwysGJlExCDtxBO5o7dfGZFQlzYV55P81cVV4lfLGc0D1bFotEiqvgxUi7Bv4nCBQ238Q0eoIK4DYh3p34Fk4eTWz+gAGG/sD1b4tFx9yE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=YR+uOTSy; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="YR+uOTSy" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 507I4DbG005335; Tue, 7 Jan 2025 18:15:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:reply-to:subject:to; s=pp1; bh=nMtpIxh08zhe3/uUyhhpzpcHOMiIp6ybY/SObDEsLRg=; b=YR+uOTSyhybp E1mEUcFCbJv2MbVWtoR+f9vWGiS97aLi29621ATHsgvhpNY8YWEmEdgPF7RBJWVp 91aXp7q971aVu1AJUwD/M729HNMEKoMi7VS2lfnKQPogw+W7oSBjx3YqtBfvMuBo tylFWyMW8RkF1tZyBterHd016OeGvbHxZnWzkCNo81FeFSXWPr0SutjA5T741YdJ 0xbeZSAwRQXisBjP3hz5kaztxJbSnRJQh7WYTlJrgGYkQEimAg1KwoCzfvPD47mF TtaOjdt+7GnEhwz6lsut4i3LcOwX+djX4BGQc8kH28Cq8DQh4eTWxArlY+Ojj1mh s8P9+oR2tA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 440vrjbsvj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 18:15:02 +0000 (GMT) Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 507IF2AC027267; Tue, 7 Jan 2025 18:15:02 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 440vrjbsvc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 18:15:01 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 507GT8iL008861; Tue, 7 Jan 2025 18:15:00 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([172.16.1.8]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 43yfpyuxtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 18:15:00 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 507IEx5722151884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jan 2025 18:15:00 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B6CA658050; Tue, 7 Jan 2025 18:14:59 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BB23958054; Tue, 7 Jan 2025 18:14:54 +0000 (GMT) Received: from [9.43.76.251] (unknown [9.43.76.251]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Tue, 7 Jan 2025 18:14:54 +0000 (GMT) Message-ID: <4952e9fd-0d85-4d4d-9bf4-ae127d612008@linux.ibm.com> Date: Tue, 7 Jan 2025 23:44:53 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch 2/2] sched/debug: Remove need_resched ratelimiting for warnings To: David Rientjes Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Madadi Vineeth Reddy References: <77e42990-0ea3-fc53-8051-6856a92ad4d0@google.com> Content-Language: en-US Reply-To: eeaed106-cb10-3113-030b-ee23ab3ad0c8@google.com From: Madadi Vineeth Reddy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 7XZ2svp5N7w4A0Sey3kAOJ2L6zhUOnTu X-Proofpoint-ORIG-GUID: fYzMhYZo7Msoauc7EhmAwQvBSA8_Sye6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1015 adultscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501070149 Hi David Rientjes, On 07/01/25 02:09, David Rientjes wrote: > 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. Any idea why it was initially kept to one warning per hour? The possible reasons that come to mind are to prevent excessive logging under high CPU contention, as well as to ensure that a warning logged once an hour indicates the issue is not caused by a short workload spike. Additionally, this rate limit might help avoid impacting system performance due to excessive logging. However, if the default value of latency_warn_once is changed to disable it, it may be acceptable to bypass the rate limit, as it would indicate a preference for logging over performance. Thoughts? Thanks, Madadi Vineeth Reddy > > Signed-off-by: David Rientjes > --- > 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();