From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ED771F63E2 for ; Tue, 7 Jan 2025 20:13:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736280793; cv=none; b=UNDqHyERXRh4zyoIkDwmvqBwjCLll93ANcDGqk/dGFYYrY/EUZRsFv/Gcr81qxkxJGCrudCpQpWSxXY7HzE361GNtvn29gB/+oBSAV7WpbbgqW9UAaHASDYizWhQWNqSf+T/Opb5QpZJukf5x09jCBmdsYIAjSTmn9Cg0BlySYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736280793; c=relaxed/simple; bh=hKZdYo/vy2zyNR3OBxY/EOlkmJXmYb8cnyJO8zkDNc4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=t/t2/+mZ9gb/xPtKALuuclybQcadtOmJK3QQucc63BhtCW/Rhj/KpmOGNpx6m41TnxtNgw2YZkQvMV6qL/zBhiVXPYOjOZxzOuuWNK9eYcH096ZvSoPS0bTSgcxPPx8pDxMz8iRgVQmqd2ht2nVPKihbOG1uiYFwGYALsjoWVpA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=PbbYaHJi; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PbbYaHJi" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-219f6ca9a81so20195ad.1 for ; Tue, 07 Jan 2025 12:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736280791; x=1736885591; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=QNqdaUG78D4aj7sYhYhKlEb0aIy/EXwDbG2CB947vho=; b=PbbYaHJiJuPNJtk3u/wWAVcyQiDeLVwxKm7EPuvePXsKVdfeUHyC0COlqImHzvtSRX QPUiU9ur/A2fkLLa4KIvTWJ2FN55TyMpcbTmxk+Vbws7zrOPVLHjEYAMi+oq4U9iYvKz R+gD4nSxf31ZAbnEpfUEdThORggGPINhAQn2K4gCVwhy2/kg6m8fDXYdemLvdHXrkzUq hhLHH8fX9PGWRTnoMv/Yvj0Q8JtdluGzL7/ejkotRLjyuphPYFimC7l6wtLh6Qeub2AX aIQ5owTHIvOO+ECkhGmIlTTCHdMo08smxgqGhbEdm8Pr2+VSbbI7wKz71opVr9avhJ1G aE0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736280791; x=1736885591; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QNqdaUG78D4aj7sYhYhKlEb0aIy/EXwDbG2CB947vho=; b=ZfFHoDNpfGO/BGZo7JRvltJAGgsVhIwroR0+id8PqlmlmfL3oh1/ZQO7mliN04TODr 59hoZrtDkj/vtAUltcDz0pUOVqUNtRvJG4pTmCovpQwiF6bFy55t2ZYHfbTjAQ78Mzy9 9yLy5Ty6LTkoA3xWGARDyFvXRzqJIpEvze55qUTKLfDSnB/2bT6UQHefkMi8AyoDxN2r 6qfIB3j+3Sqky/Ck01WYWHl1+q7KjmUhlkvULTNIW0EqUQ6hhHqg8l7/AYMOOPPBU3Cm wCAjrkCdmVgMLYABbzLB6zNL3SyVtoJaDKLm8p9OdKsK2IgOGS7c1PYQ9BlbuU+a0KgD fQ6w== X-Forwarded-Encrypted: i=1; AJvYcCWNEkXwD+xAWTUCU0ptZfJbKPH2JWkTk6e3HcpbM7yRmYqfM0mXyanyKw8aAv1/2g5mSs/RyPDwh0f/Vts=@vger.kernel.org X-Gm-Message-State: AOJu0YziWs6uGvIUY3YlcB6ICD0dSuM1qz0V3rfS5WnLq8Xgb5XY6QKj +KszbmUQbtRWfrexlp7eNvDrluieZL6UauqTKWBPw6Z9GGByWVSYoYkVrE1JAA== X-Gm-Gg: ASbGncvDH5fz5UuCNiLMeaX3OVHBCKK1wqK5k5xzuTKeqK8LUHXK0d8gi1lOEp/xXZQ q7IQ7w6eY64Dj2Nurg0yJ7R8C0SVsr0amc7IAl5R+OzBCQkDa8ZX/EgMOxFt66c3h4uG2FIolq7 2sX/KHgguUqJjWjGLMmiOc9FXB4Ogmr92njQ2L1jfzJ45dOeos87B/G87EXf4pMvXTlwzrZ20DO JOnJWQn17TD6oBodP7BpmKlW8cSylASCXYbDjzN4fkKVg11X+Hnyq4Xvuw2Fvtyf8cKwVvjOxkb L6N8XaJyEmQ= X-Google-Smtp-Source: AGHT+IF8yVn1H5z9pw0fNZHMIiwVQEEXQMPrtSOnnXrdQH2x/hKpN9A3OJcv72JDDYEGHJ4OW+O28Q== X-Received: by 2002:a17:903:32c9:b0:215:4bdd:9919 with SMTP id d9443c01a7336-21a843b2e38mr225745ad.17.1736280791234; Tue, 07 Jan 2025 12:13:11 -0800 (PST) Received: from [2620:0:1008:15:7400:e051:ee31:45ec] ([2620:0:1008:15:7400:e051:ee31:45ec]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad8164desm33715583b3a.18.2025.01.07.12.13.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:13:10 -0800 (PST) Date: Tue, 7 Jan 2025 12:13:10 -0800 (PST) From: David Rientjes To: 99090633-b625-ff07-fcf8-500d71f9ae13@google.com 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 Subject: Re: [patch 1/2] sched/debug: Change need_resched warnings to pr_err In-Reply-To: <833e94a8-738e-4107-81a9-68314cc99954@linux.ibm.com> Message-ID: <54cda6c8-38b5-5a98-5296-df40369889b7@google.com> References: <99090633-b625-ff07-fcf8-500d71f9ae13@google.com> <833e94a8-738e-4107-81a9-68314cc99954@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 8 Jan 2025, Madadi Vineeth Reddy wrote: > 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? > Thanks! I pondered the log level here for about five seconds, I'm indifferent to pr_err() or pr_warn() :) Since the stack trace is the most critical element of the output here, imo, and it has its own log level, I didn't feel strongly for either err or warn. > Reviewed-by: Madadi Vineeth Reddy > > Thanks, > Madadi Vineeth Reddy > > > + dump_stack(); > > } > >