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 9C54B3A7840 for ; Tue, 24 Feb 2026 16:13:10 +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=1771949590; cv=none; b=CpFGipEqFdP2y85iqz+WFad9yadiEzYut1Y0HvGCbqBBPYheOSbsdLywv2dOYhGFO5Ae4ueegH0ABgJzYx0+wJ0KwznQBTC4LdaJE7q0S9HlZz3ZDWff6JTN0bqSHZdfv5ie0DVU2La5CChK8MBcfcKyraHM/ZOOF/7Hx1jASwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771949590; c=relaxed/simple; bh=Fy229t0O7kWRKuBFfMLqTu1ym9mO364Dtzj8pz1CUGw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=i2jU1Gk9Pj7AoWGxhJsKrPlx2ZfyzfolwPT61vqg6PaMkuxFtxTtPaYVqTP83AmNFdcwxTpjWphTH9zbksoX42SgPkc7e/D5BPgrsoxJyD0262l0burRhUMhYowrq+9JHW0ptUdb+PlbfPedGZv1QRNGSeDNhU7N/UnqY1pmazY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E3Mpq+T5; 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="E3Mpq+T5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4623C116D0; Tue, 24 Feb 2026 16:13:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771949590; bh=Fy229t0O7kWRKuBFfMLqTu1ym9mO364Dtzj8pz1CUGw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E3Mpq+T5Vxg+LsDaUpuHbt8SQZh39I4feciikfHN+vlQpLnQQwO7u3BOwcjPrbyF9 VCOQrEkT1kx8Vj5/+RbhQJkBX/GA6cHVmYQEfQR8Iy5abVfTKQbFk1axYyXWkrge92 i7WoU6L8jpDffKnuVuyXMSsSQfsuvgB10S09UGDmWvtNBjrNCtx6PmMJBzPFby0UDx E/qGqPjAUZTOmyGwsrcYQXSdKBgUj7td3orq+PZxgud0oLHKzSWwwTrIPbtD6jOfHk Aq7bvio9JE6n1k63BVxW0wI2RtPo2IkSr9FIdN9nprbq+wyX6jl2IzN5lGlTxdzwfa uqeWSEovMln1w== From: Thomas Gleixner To: Christian Loehle , LKML Cc: Peter Zijlstra , "Rafael J. Wysocki" , Frederic Weisbecker Subject: Re: [PATCH RFC] tick/sched: Prevent pointless NOHZ transitions In-Reply-To: References: <875x7mv8wd.ffs@tglx> Date: Tue, 24 Feb 2026 17:13:06 +0100 Message-ID: <87zf4yt90t.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Feb 24 2026 at 09:35, Christian Loehle wrote: > On 2/24/26 08:32, Thomas Gleixner wrote: >> This happens with both TEO and MENU governors in a VM guest. That's not >> only pointless it's also a performance issue as each rearm of the timer >> implies a VM exit. > > This is the (drv->state_count <= 1) case I assume, no governor does anything > sensible in that case. Indeed. > I was also curious about the performance angle recently FWIW, but didn't > hear back: > https://lore.kernel.org/all/73439919-e24d-4bd5-a7ed-d7633beb5e4f@arm.com/ Sure, but I can tell you that two VM exits for a 10us idle are really harming performance a lot. That's why I noticed. >> Keep track of the idle time with a moving average and check it for being >> larger than TICK_NSEC in can_stop_idle_tick(). That cures this behaviour >> while still allowing the system to go into long idle sleeps once the >> work load stopped. >> >> Signed-off-by: Thomas Gleixner >> --- >> kernel/time/tick-sched.c | 20 +++++++++++++++++--- >> kernel/time/tick-sched.h | 9 +++++++++ >> 2 files changed, 26 insertions(+), 3 deletions(-) > > Why here and not in cpuidle? I don't care where it is fixed, that's why I marked it RFC > We've recently added some code for the single state case to skip > governor see Duh. I just noticed, the VM has no driver, so this will not end up in cpuidle_select(). No wonder that changing the governor has no effect :) I set the governor to haltpoll now, but that does not work either as the stupid haltpoll driver is built in and not activated as it requires the force parameter unless the KVM hypervisor has KVM_HINTS_REALTIME set. Brilliant, intuitive and truly user friendly stuff all that. It's amazing as always that all the "performance experts" who cry murder on everything else never noticed this completely nonsensical default behaviour. Force enabling that driver and setting the governor to 'teo' makes it go away. 'menu' still sucks pretty much the same way as with none; slightly less so, but often enough. > e5c9ffc6ae1b ("cpuidle: Skip governor when only one idle state is available") > where that could also live. So either ladder or the powernv driver is broken and that gets fixed in the cpuidle core. Interesting choice. But as I explained above adding something to this hack won't help for the VM case with no driver active because cpuidle_not_available() is true and idle ends up in default_idle_call(). So either the governor/driver muck provides some sensible default implementation or this has to go into into default_idle_call(). Oh well... tglx