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 0930E363084 for ; Mon, 2 Mar 2026 11:39:55 +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=1772451597; cv=none; b=IGZC5EY9RadZxcfhMCU9UEQepkElKjwfmG+gF2isEaAFJVDgs9Rjnu06r9/srGVRJ6jmZZFZyqumunWAVOrfNpZfcQYJDLLz9kd9LyEjL/ea3tfK+/Bfb/m9o88HA+2JogYiY3qYNlkW8pJXEzr15YectHiWgmJOBwKS/E5JzN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772451597; c=relaxed/simple; bh=J2fTWclTDEH2xy+Wd2O2VqSVj+i89IxPHA+UnEmOi0Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GDGuuwfhDB1xDCxsP0DjnuvPG3U9OEzutIPj3RebAP8kzhVIP6m6o9LGw3/eUrf2EHhBbknt9dF7haz+lZU64TuwZjx6yh2rycjqLO7Mdy0prSUgFRV0HjQI05EZKwGlT2TKUi8367GUASCCCN5DMaAbnXXg6QcHVL3LHnC0xq4= 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 2926A14BF; Mon, 2 Mar 2026 03:39:49 -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 E32ED3F73B; Mon, 2 Mar 2026 03:39:53 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 11:39:51 +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 Cc: Thomas Gleixner , 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 11:11, Frederic Weisbecker wrote: > On Mon, Mar 02, 2026 at 11:03:00AM +0000, Christian Loehle wrote: >> 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). > > I must confess I don't fully understand the picture with the non-existent states > but what Thomas is doing in his patch is basically an ad-hoc implementation of > cpuidle governor decision whether or not to stop the tick. > Yup and if we put that into the cpuidle governor then we have to duplicate that logic for all governors even though for <= 1 states they hopefully should be the same. A dummy driver would allow for this logic to live in drivers/cpuidle/ but I don't have a preference either way.