From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8732F1A9F90 for ; Mon, 2 Mar 2026 11:03:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772449386; cv=none; b=r4MHivo2MwFpg5xaWZj4OQYTLXE6NhHxrLEaAfyM1XVu3R27zYU0DpirKmM0g+Fr9bYFnV45hY/g0PVQFH97f68R06j/YAb51h6Sw3Sdwj1lca83IqCHNHKmbkeZuDefKqFBB5KLYOSAtdHdQp8L9jUveL2VEvf8lyHfoN24FNw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772449386; c=relaxed/simple; bh=fmOHA+moQTV0DMiaMX/ot/hrvkG76anKATIYW45swvU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=D+SCgwKchA2m9mMze664y2cWza3G3K+q5eg50J96vmv3XC8Xg73ixuI5QVzdjUCkqM+J1UQE6jyNgcXwfWaZWULghmWnYWeuujG56WGN2Mj+EjyhkLVIFcVecmzruz0Usmd6D+3fCN7gKK7Pzv1nPsqs2GMBUzTcy/EhSWSWM4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 69DF614BF; Mon, 2 Mar 2026 03:02:57 -0800 (PST) Received: from [10.1.36.25] (e127648.arm.com [10.1.36.25]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 962FA3F73B; Mon, 2 Mar 2026 03:03:02 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 11:03:00 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch 2/2] sched/idle: Make default_idle_call() NOHZ aware To: Frederic Weisbecker , Thomas Gleixner Cc: LKML , Peter Zijlstra , "Rafael J. Wysocki" References: <20260301191959.406218221@kernel.org> <20260301192915.171574741@kernel.org> Content-Language: en-US From: Christian Loehle In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/2/26 10:43, Frederic Weisbecker wrote: > On Sun, Mar 01, 2026 at 08:30:51PM +0100, Thomas Gleixner wrote: >> Guests fall back to default_idle_call() as there is no cpuidle driver >> available to them by default. That causes a problem in fully loaded >> scenarios where CPUs go briefly idle for a couple of microseconds: >> >> tick_nohz_idle_stop_tick() is invoked unconditionally which means unless >> there is timer pending in the next tick, the tick is stopped and a couple >> of microseconds later when the idle condition goes away restarted. That >> requires to program the clockevent device twice which implies a VM exit for >> each reprogramming. >> >> It was suggested to remove the tick_nohz_idle_stop_tick() invocation from >> the default idle code, but would be counterproductive. It would not allow >> the host to go into deeper idle states when the guest CPU is fully idle as >> it has to maintain the periodic tick. >> >> Cure this by implementing a trivial moving average filter which keeps track >> of the recent idle recidency time and only stop the tick when the average >> is larger than a tick. >> >> Signed-off-by: Thomas Gleixner > > Shouldn't there be instead a new dedicated cpuidle driver with proper governor support? I think a dummy cpuidle driver is an option, but calling into any governor seems overkill IMO, it presents an option to the user where there really is none (after all the cpuidle governor would just make a boolean decision as there are no states).