From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 E0073198A32 for ; Thu, 9 Jan 2025 17:59:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736445554; cv=none; b=TGxFyXtT+FwzC+zDkdU0HIBHpOdtxaf6rQjB0L0WV4C2p+gFdk+F7Hb31LrktIt2n1QjLb32BLpFKHPdQTveXmrY1OtkgwYXsTIq7IYrDU/V9YDxPVFa1Ox8gE2VzYpYHwL0krwZkbbFkbF371VLUe6hqevvzS4gF0G8cUxcgtc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736445554; c=relaxed/simple; bh=LSsXFyu8RZr9/Ls4VBKd3RAXmsZeVsrUUbkmDqwnEXc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=kQ0wBctyV0HkafwmLzgHf/3cPUC7xuE79rej3mFzWD8N5fFWMoFrIwv6V0SjgyOblEXLGENm6YENKy+8cQK2ZMM6uOXlnF8CXAJabmyEtkJAhC1HIrsoQED1i8eXhnl0DE4OYcgQ8rr0Z4rwVMBUSDvWvWEP1JhYmdVkgPiY/aM= 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=P0jewu2y; arc=none smtp.client-ip=209.85.214.180 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="P0jewu2y" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2163affd184so2475ad.1 for ; Thu, 09 Jan 2025 09:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736445548; x=1737050348; 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=Gg+etn9GmP3xCnw96QKdzZdEPtbp+TqmjLRfcYaM0N8=; b=P0jewu2yOBATJvTuIKnI+K6I/e12oGBIHyesTPpj47+ZTAKWMCcgKYSSKEzRl+jr8m 1QZfwh0vv3doVsozdZK4VBi4YO3Bd96RBks2XBQFcYOIM8lzg/nj2lMgJ41r3J3gOjXL nL5aSdIFHtyDnOd99Gy21xogNMjmKWW8xlnUBoGoG8eA9n6ljALvSd12azMhrwiM9koM f42yFSTdpB58Aty8+Z0dJIj7y3VTnuxABk8Z0Wf2+8vCtJHKm9GOvjMbH4kxMz0lwxks cVvvIaNS3ko8KSu7sJRBRM8FA2fwgDRUVUkp1BDWRdlUpTwiBAGcMq2Yi14Yzctf18E3 5Swg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736445548; x=1737050348; 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=Gg+etn9GmP3xCnw96QKdzZdEPtbp+TqmjLRfcYaM0N8=; b=LM+sVDcgWgb4MsqejaQHIEjT1d+54CT8LkqerZEbT0SbRRU5DjClllTP+y3ZOR1tYT SB3ykF4l+tI61fboabagVJk1oqrrq2lKJ45lrPcAj7r9FrW/HFWVn1SGw4tIjESrvOjZ lMl6UutnaJSt8wxL24tjpy7Kk3jKmId6rYxxMwIbaTvIt9XtlvF7t2D/GeIsrqLXSXnw ImPodRNvdeHDY+xj9xhgnqcj5V3tevM4kZ9FHdWQtmkYgTvTHTpYjBgUOm9FI25QvKCS l8jS0TNSusTqjnS40i1x85Gqq0J2BHwZkj5bBzYToSvqMVI4FHm2NOK7A8uIOdVz0HBf V/sQ== X-Forwarded-Encrypted: i=1; AJvYcCWoLCAjolv1vtZbmrKVn96qhKisxH9VFuKxLRmhbCqJ25m/zDfq3VBKK5Gyj8EBSkMMo0VsqHAs2Ar/e3I=@vger.kernel.org X-Gm-Message-State: AOJu0Ywmu/Dv1sKeeK1QVlHbYmfbQQyGW7EcK5P6CgMoTM31eiZVxgx7 c7R6BYs8ozhXiUvewt4Pp7VdmYxy/3Ft4K8g3KLqkVUsInA+YG5Or0HuU19dBg== X-Gm-Gg: ASbGncu4NYoe+3H9SGHjSvo3lDPH2CAg8xhoutnqMNKboI7S+GLzHt0RjZxTEi5Ra4K J9LrCBXJ4cQOmO7Zxb/vIFIb1f5Po8BteBareabUyn4PMfsrF2vglXB+ZuOlxzk5RF0/g1obyVD bdAOUvcaWi5EuLkHbrITnz+gZZkbqZzrltbuaxdYLEGvkRZCjvMobHaSdixuGpvq06ks53DRa6H pxHhBd5/JHQcDcqpUbRQ0nkD1jcR9WrnCLtx424l15e5FG4DiEnS7Ba5wemFw0vl7pIKVjhLYFZ zjHGL8k8 X-Google-Smtp-Source: AGHT+IE52z6WfhPCgQHWo+q8HpNQVCewE0EgOZuvg6sIkT1n/pyUuH5sLIOtrcmzaSAnT/ZIOlYbVg== X-Received: by 2002:a17:903:258e:b0:215:f0c6:4dbf with SMTP id d9443c01a7336-21a8ed38c9fmr3087115ad.14.1736445548353; Thu, 09 Jan 2025 09:59:08 -0800 (PST) Received: from [2620:0:1008:15:cf2e:9cf:7702:214c] ([2620:0:1008:15:cf2e:9cf:7702:214c]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21a9f219330sm703595ad.132.2025.01.09.09.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jan 2025 09:59:07 -0800 (PST) Date: Thu, 9 Jan 2025 09:59:07 -0800 (PST) From: David Rientjes To: Josh Don cc: Madadi Vineeth Reddy , 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: Message-ID: References: <77e42990-0ea3-fc53-8051-6856a92ad4d0@google.com> <4952e9fd-0d85-4d4d-9bf4-ae127d612008@linux.ibm.com> <85f483ed-845c-a25f-3558-e1a8629e9200@google.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, Josh Don wrote: > > 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. > > Your change doesn't reset rq->last_seen_need_resched_ns, so now > without the ratelimit I think we'll get a dump every single tick until > we eventually reschedule. > > Another potential benefit to the ratelimit is that if we have > something wedging multiple cpus concurrently, we don't spam the log > (if warn_once is disabled). Though, probably an unlikely occurrence. > > I think if you modify the patch to reset last_seen_need_resched_ns > that'll give the behavior you're after. > Thanks Josh for pointing this out! I'm surprised by the implementation here where, even though it's only CONFIG_SCHED_DEBUG, we'd be taking the function call every tick only to find that the ratelimit makes it a no-op :/ Is that worth improving as well? Otherwise, please take a look, is this what you had in mind? diff --git a/kernel/sched/core.c b/kernel/sched/core.c --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5659,8 +5659,10 @@ void sched_tick(void) rq_unlock(rq, &rf); - if (sched_feat(LATENCY_WARN) && resched_latency) + if (sched_feat(LATENCY_WARN) && resched_latency) { resched_latency_warn(cpu, resched_latency); + rq->last_seen_need_resched_ns = 0; + } perf_event_task_tick(); 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();