From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 12D141F63FE for ; Tue, 7 Jan 2025 20:15:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736280922; cv=none; b=tqFkCI7gSavMo1MMaUXVyMp2WaxwGmOt9Ihq5MAJFAwmxDUGlD1LCd497avA6OiHEmNNLJkR1i+S+xjYl6uPoc9EgMlyHyGlHjH/bGIy91Okbn8MCODuTDB+nm3ecLwDDk7TcAWyrX94mqKeeiRJtQy01J1qHVTRONSQjkAZEt0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736280922; c=relaxed/simple; bh=UU6HHNSquLQDsGmyX4ABL8fRxBC3YK7jNFt9CE4bQxo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=qb0qDs7T2PKkXq37EbHpa0MKX2LOAkpTkfqM6OmYF6IfuTeVjRjScBBMqIhWXBPV0B7RPwMEUubWtqsnTiajgscnxiZgnMMQNDLMQbCwUkbamT335HADa1HMmJc9HGO9z7ajDCPCUYa9pAKmzfkV8XQVBveGqsrgP4XgMAMW8wA= 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=YnDl+1rJ; arc=none smtp.client-ip=209.85.214.171 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="YnDl+1rJ" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-219f6ca9a81so20475ad.1 for ; Tue, 07 Jan 2025 12:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736280920; x=1736885720; 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=JpCj57wGsuXVXbPJMdEhe3lg7nzrZqCv7sgxsKyfDSs=; b=YnDl+1rJ3JjKsbYtINvTb/I8l11QUYIfovbRF/2e3xJwzyUINzVkA2LpaKf2N9wWtd 0D9jBmSBRAtyODmQE/HTwmPK56OEtKsUC5mxDBjB12b3Z3IUCH0MzAoPioGV+iJ4TXT7 zKhAupY/ZSzsg4ekQEyx9Y5dWQnGGQXoyLUHWcI4IEs1mj2yWUmCSaXWT6gD0EPiAFO8 b4aCPRjEct8iVoMLXeAa/ED0lUEAhbYV+cF69Uu+52rBrxucysjwAtXuwrZ5Jcs+9aUJ TxsM+VuJDmgbGdYeQoZLuTEz5Aans3okV0EmATB3WlnaxsIdWgtQU5pOWE+ZFkTqFR1D 3/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736280920; x=1736885720; 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=JpCj57wGsuXVXbPJMdEhe3lg7nzrZqCv7sgxsKyfDSs=; b=eOPzyA+RWimRfzfV20xmxHENM+SFmQLvMWuuZMdK5zdMGxDLfd6dYHHSh8iBbXJUZ3 eSC+txDgICeOSsPNIB/s0fR8LqA/77K+9VwKH3fR+XysuUpXSBzs3iN8vc5jbPTfPJwo puDpJDjDu0/BOwFu+ylHncQ0Ij4xx9G4x1faI23BobRj1AAPCqxJ8V/oYP0tOabbJIi5 /6DNcE8UDjbjr+ZL6q2JspMc65yYGhUnWy5MXK7jCRZwfoNOQFErLkkaFCmnPMdQjFS4 XEZr9kfMbmf4xDAfbd0ZHlVf7YfDVVcZYyOvXDDtL+9ZiUatNabKiNjam9XV7gslgROX e2sw== X-Forwarded-Encrypted: i=1; AJvYcCXfWsnxh1c9CmZGQB67/KOHZpgzphB3FwJg7yWo8voGES+tWVR5g2OUSd3+sdB9yOOloCK75lz7IaexBdw=@vger.kernel.org X-Gm-Message-State: AOJu0YyJ5LzK6MulHn1Veuu7y0zniH1g/wfwMLxqWnTg92sL9pdviFUD NusKb1+ZZy8G60rZWi+SXrfmUhVO54d3ZtYX3gXPQ3fvuA5UekWBu/L6EiohCQ== X-Gm-Gg: ASbGncvTRkwxQRdECN/KRQ92xTC1m2cgVfaNCsai5zOgeG3UbDqDZY6+WMkcj61Y7j8 G8KLIqQ0OzMgjUK1NgxTh3rg0Jp9RquP5A41H/+tMqFD3mSnOugHrQFmEkM0JTPLvdST0DUezZo 86BUC2ohDJwymSGJLfY6SASpaHlU9l3llPO1pRIFktTptmmzmUE4Sde1UOQGxf/N50nRVObwW4C G8+Y9EI34Wu1528Qf5vZ/Kf84sSXZwCNmD3ytbdfEZTViFBmPmD9FdbGtJW0tWWNAFKcxianGWm 0dUacN9ud1c= X-Google-Smtp-Source: AGHT+IFKR6RpbLlwmGy1UbGVNqKpqo3Z44ApQbb/mW/wjAznSN+0gAh2D9V6z8llgbTkg1e6GhYzSw== X-Received: by 2002:a17:903:41c6:b0:215:9327:5aed with SMTP id d9443c01a7336-21a8418a551mr321705ad.20.1736280920111; Tue, 07 Jan 2025 12:15:20 -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 98e67ed59e1d1-2f4477c8583sm36300428a91.16.2025.01.07.12.15.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:15:19 -0800 (PST) Date: Tue, 7 Jan 2025 12:15:19 -0800 (PST) From: David Rientjes To: Madadi Vineeth Reddy , Josh Don cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Subject: Re: [patch 2/2] sched/debug: Remove need_resched ratelimiting for warnings In-Reply-To: <4952e9fd-0d85-4d4d-9bf4-ae127d612008@linux.ibm.com> Message-ID: <85f483ed-845c-a25f-3558-e1a8629e9200@google.com> References: <77e42990-0ea3-fc53-8051-6856a92ad4d0@google.com> <4952e9fd-0d85-4d4d-9bf4-ae127d612008@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 Tue, 7 Jan 2025, Madadi Vineeth Reddy wrote: > 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? > Adding Josh Don who may have insight into this historically. > 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. > Right, I think this should be entirely up to what the admin configures in debugfs. If they elect to disable latency_warn_once, we'll simply emit the information as often as they specify in latency_warn_ms and not add our own ratelimiting on top. If they have a preference for lots of logging, so be it, let's not hide that data. > 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(); > >