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 876041F428E for ; Tue, 7 Jan 2025 19:18:50 +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=1736277532; cv=none; b=FmYb9vGBtFDDFBsjHeB7Is51ummuwphuVcNaURYnEsLjz4+GTebzEw/zOLNXxhzzW3oc+6YYOkDvRQFiRPkGnxINLxD01Cmf5lR1Ujofuhba0YLfLOTPh3B8MCwrwMUEV0I0rWOpD+9KaZCD9uN1tAAXxhlTsxZtfTgsbvjdqdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736277532; c=relaxed/simple; bh=WyV1R77MyIPTt7YTuZ5XV5YpuFViCQ4CbTD/n4UvUIM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iXigozdqdSVRgTCnFZnOMp5kEocExvIZ0DfaDkEWZUX4zmpBdqO7jLlX+Ok0pba0XdMGHYv5Lpi+P4FhGBBH3nKGeEnEANrumKqA0DkQs8ZNpiYRIUGst0/HhUdsg2nB1JZTSTY1GOZZcqcLH9kqmbk/UTycnB1L0Lo3C2mJijg= 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=EOoCNX+F; 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="EOoCNX+F" 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 507IpaYR011061; Tue, 7 Jan 2025 19:18:32 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=RBZpL/RsrB2z8oQhm2l6k5J4cGPrN76yrj4fPiQf114=; b=EOoCNX+FhvLX S1vIx/wlUebVxGX0w7PnWyDVWOAD4pMDCAQ0ipreBXs/twMflJjyMbGWLx1OOLUH tnKFvTSrMz5JG/M5/6EEgTvl1iWobGEnVaMvawdsnPTwf6LrKYSbBg8u7EmYsyI7 /NceHLm4ZDaUR2C5/hJLo3OLAHaiWhxgSIpP+x5Uhf54ur1D2rAS2UQvqjpVCUj+ 8cbFbCEtJmhjR4QUQnX8MFodBsyUtTZOUXwHZX+RlqDV3f6vxLND6i8Z+KunRKdf QvTeeMFHhv2ZAzpArjRtFU8SKQnoLYm0WavnwzQMFxycRW4SojDhvBafDnzDsmWg 48NeUA7qug== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 440vrjc4n8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 19:18:31 +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 507JIV1T007513; Tue, 7 Jan 2025 19:18:31 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 440vrjc4n5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 19:18:31 +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 507GQPsF008869; Tue, 7 Jan 2025 19:18:30 GMT Received: from smtprelay07.dal12v.mail.ibm.com ([172.16.1.9]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 43yfpyv7ps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2025 19:18:30 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay07.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 507JITGE65732920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jan 2025 19:18:29 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1DE2458050; Tue, 7 Jan 2025 19:18:29 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E123858052; Tue, 7 Jan 2025 19:18:24 +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 19:18:24 +0000 (GMT) Message-ID: <833e94a8-738e-4107-81a9-68314cc99954@linux.ibm.com> Date: Wed, 8 Jan 2025 00:48:23 +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 1/2] sched/debug: Change need_resched warnings to pr_err Content-Language: en-US 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: <99090633-b625-ff07-fcf8-500d71f9ae13@google.com> Reply-To: 99090633-b625-ff07-fcf8-500d71f9ae13@google.com From: Madadi Vineeth Reddy In-Reply-To: <99090633-b625-ff07-fcf8-500d71f9ae13@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: JVCByvYoX0fZPUz6S5zPGc8_Wh8Vu_Si X-Proofpoint-ORIG-GUID: ZsKq50Lp2KeVab7_Svg8ZRi3451TSiwJ 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-2501070155 Hi David Rientjes, On 07/01/25 02:09, David Rientjes wrote: > need_resched warnings, if enabled, are treated as WARNINGs. If > kernel.panic_on_warn is enabled, then this causes a kernel panic. > > It's highly unlikely that a panic is desired for these warnings, only a > stack trace is normally required to debug and resolve. > > Thus, switch need_resched warnings to simply be a printk with an > associated stack trace so they are no longer in scope for panic_on_warn. > > Signed-off-by: David Rientjes > --- > kernel/sched/debug.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c > --- a/kernel/sched/debug.c > +++ b/kernel/sched/debug.c > @@ -1295,8 +1295,10 @@ void resched_latency_warn(int cpu, u64 latency) > { > static DEFINE_RATELIMIT_STATE(latency_check_ratelimit, 60 * 60 * HZ, 1); > > - WARN(__ratelimit(&latency_check_ratelimit), > - "sched: CPU %d need_resched set for > %llu ns (%d ticks) " > - "without schedule\n", > - cpu, latency, cpu_rq(cpu)->ticks_without_resched); > + 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); LGTM. While this is an issue, it doesn't necessarily indicate a critical failure that would require the kernel to panic. Nit: Would using pr_warn instead be too lenient in this case? Reviewed-by: Madadi Vineeth Reddy Thanks, Madadi Vineeth Reddy > + dump_stack(); > }