From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B216228A707; Mon, 4 Aug 2025 16:54:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754326478; cv=none; b=QZLCgg+IyY5BMhpF8UegY47xyjYNye7yvE2Fkj7B/9JJC0Wqq6UMMObCBBqJUl85bEzHceHoQr+vcl9j9hCWxbXvcq+VPYo3jNkvFJr44/sGDHzepIcHW2v39hjO3LHw8Y/9N5DL3SNJvLq032RdkkruDYuUHZcQ0wOgLdsvxto= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754326478; c=relaxed/simple; bh=d+XlqNAsTP1aZFEzzzw1zGerTeyCFUUm7vWEU3d2zmA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=A8B2VbHKc66VAcnAEJ2KWxoE4tA0q8gRqwSRJEj8diwe925D1T5TzsFj3zZxsKERslIHIvPCsvwhyImqDpCcuHVnuNA+qGfFRNTgJ8H+Jc7iha1ebBJuofMvHJbMH8/yTIXd6TM6opCUEATITIM9MaiUqi+4wgJWu/edpGn/EVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cOHfjh2A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cOHfjh2A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31447C4CEE7; Mon, 4 Aug 2025 16:54:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754326475; bh=d+XlqNAsTP1aZFEzzzw1zGerTeyCFUUm7vWEU3d2zmA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cOHfjh2AohfXyPVoX2YaEpfGzdr+X7AiTfo+cPeM0jwBNjq6KMwOiIo1bxO5vspXI hfhK2B5N9aTAT0EFuokAeGbp/JmvOUUWE57EaBuH9NFzoifgite9SuOv+E0dqaeAKJ d5DTJ+dkQDIHv+gNd8fM2LILh+mpTCB+i01fKwynAJPoUctQQPX4LIfETdkeI6fMKH gf+4cf9Nw/IDLNmklkqq3mxRY4ajLwHqwXCENvhRxJaQrWnhq3U0fyE898tQiQ+os4 pPX/Z4X5MW8yWud3Hl0+oNE4/lBh485CuPIpmoNE0YSGst7vE4Z4Czj+XZgp4jfWwo fMF+OcjSDGbzw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uiySG-003sNW-Br; Mon, 04 Aug 2025 17:54:32 +0100 Date: Mon, 04 Aug 2025 17:54:31 +0100 Message-ID: <86o6sv6n94.wl-maz@kernel.org> From: Marc Zyngier To: "Rafael J. Wysocki" Cc: Linux PM , LKML , Daniel Lezcano , Christian Loehle , Artem Bityutskiy , Aboorva Devarajan , Thomas Gleixner , Mark Rutland Subject: Re: [RFT][PATCH v1 5/5] cpuidle: menu: Avoid discarding useful information In-Reply-To: <7770672.EvYhyI6sBW@rjwysocki.net> References: <1916668.tdWV9SEqCh@rjwysocki.net> <7770672.EvYhyI6sBW@rjwysocki.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rjw@rjwysocki.net, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org, christian.loehle@arm.com, artem.bityutskiy@linux.intel.com, aboorvad@linux.ibm.com, tglx@linutronix.de, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false [+ Thomas, Mark] On Thu, 06 Feb 2025 14:29:05 +0000, "Rafael J. Wysocki" wrote: > > From: Rafael J. Wysocki > > When giving up on making a high-confidence prediction, > get_typical_interval() always returns UINT_MAX which means that the > next idle interval prediction will be based entirely on the time till > the next timer. However, the information represented by the most > recent intervals may not be completely useless in those cases. > > Namely, the largest recent idle interval is an upper bound on the > recently observed idle duration, so it is reasonable to assume that > the next idle duration is unlikely to exceed it. Moreover, this is > still true after eliminating the suspected outliers if the sample > set still under consideration is at least as large as 50% of the > maximum sample set size. > > Accordingly, make get_typical_interval() return the current maximum > recent interval value in that case instead of UINT_MAX. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpuidle/governors/menu.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > --- a/drivers/cpuidle/governors/menu.c > +++ b/drivers/cpuidle/governors/menu.c > @@ -190,8 +190,19 @@ > * This can deal with workloads that have long pauses interspersed > * with sporadic activity with a bunch of short pauses. > */ > - if ((divisor * 4) <= INTERVALS * 3) > + if (divisor * 4 <= INTERVALS * 3) { > + /* > + * If there are sufficiently many data points still under > + * consideration after the outliers have been eliminated, > + * returning without a prediction would be a mistake because it > + * is likely that the next interval will not exceed the current > + * maximum, so return the latter in that case. > + */ > + if (divisor >= INTERVALS / 2) > + return max; > + > return UINT_MAX; > + } > > /* Update the thresholds for the next round. */ > if (avg - min > max - avg) It appears that this patch, which made it in 6.15, results in *a lot* of extra interrupts on one of my arm64 test machines. * Without this patch: maz@big-leg-emma:~$ vmstat -y 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 65370828 29244 106088 0 0 0 0 66 26 0 0 100 0 0 1 0 0 65370828 29244 106088 0 0 0 0 103 66 0 0 100 0 0 1 0 0 65370828 29244 106088 0 0 0 0 34 12 0 0 100 0 0 1 0 0 65370828 29244 106088 0 0 0 0 25 12 0 0 100 0 0 1 0 0 65370828 29244 106088 0 0 0 0 28 14 0 0 100 0 0 we're idling at only a few interrupts per second, which isn't bad for a 24 CPU toy. * With this patch: maz@big-leg-emma:~$ vmstat -y 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 65361024 28420 105388 0 0 0 0 3710 27 0 0 100 0 0 1 0 0 65361024 28420 105388 0 0 0 0 3399 20 0 0 100 0 0 1 0 0 65361024 28420 105388 0 0 0 0 4439 78 0 0 100 0 0 1 0 0 65361024 28420 105388 0 0 0 0 5634 14 0 0 100 0 0 1 0 0 65361024 28420 105388 0 0 0 0 5575 14 0 0 100 0 0 we're idling at anywhere between 3k and 6k interrupts per second. Not exactly what you want. This appears to be caused by the broadcast timer IPI. Reverting this patch on top of 6.16 restores sanity on this machine. I suspect that we're entering some deep idle state in a much more aggressive way, leading to a global timer firing as a wake-up mechanism, and the broadcast IPI being used to kick everybody else back. This is further confirmed by seeing the broadcast IPI almost disappearing completely if I load the system a bit. Daniel, you should be able to reproduce this on a Synquacer box (this what I used here). I'm happy to test things that could help restore some sanity. Thanks, M. -- Without deviation from the norm, progress is not possible.