From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 A64B2367F3D for ; Wed, 4 Mar 2026 03:35:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772595333; cv=none; b=Anuaih8NFYFbga5Wsdlef7ho70L1DkLGgrVd6zctnAZLSOQwlo+LzD859G6rxBlVBYfo7CTEJswsGSuttrZ8a9Hjys02U+kQPLAVcTM6JMh9bXSf0PGdtsaxpL4ji9Z9uePC5z06yLb67P1oK6hYbOFQeVQKOCTIYw65ZwQxrHU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772595333; c=relaxed/simple; bh=o1MiXKcXYFZw03k3sSISBkkfq96xSzpyvzErjL9joI4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WiiL8lnMJot9XoWnLzgL8rQZkAYxg4QXKVqGPcmT/yzg65rrJKrIrEyi/m3W9IEiLNzPpG2qbasXZ5tITUQIzYfBFU21WkLUP/EOaZD8YYRXp1Q3MBV4OGdlEjKQqSfp2PxxAQsgSVVQ5SB4YFb/fGOpyzh51pSsisPWHAMXOLE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b=ntj4TCJN; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b="ntj4TCJN" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso52878545e9.1 for ; Tue, 03 Mar 2026 19:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1772595327; x=1773200127; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OpIrm3j3uJPWqbUKli2gzECKjmYnxa8lu+ueajoi96k=; b=ntj4TCJNvejgtmSWoDFUDhdOzU8GqjjD1OfruKnZYCYrehXDKOJDDXr5fTB5Dd5knj ethm65Le6lyN+ja/h3QMYiSbu5CrSnKkCiwQ+4u6lCwwv9SP8JnTIUhpdqYQTBzH1+2Z tEpcBZOcUQFdlyaDp/zhm/uh6WY/a8APBwlIbOF85G5tL/SynNtxJQvuHG/sHde0IBfz AIFPIIHAyXC1K4ktm17/yiOeIWEdMJCh37H85xh+G6KT0/lkg4hiLtl5jnGnP/LgWzpj 656az0gzpBjcNofXzJuCgiJRRu8uHrdix9De5mWyCgnGhAzZYBcYXr5IKjVvNJeyxFR2 k5PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772595327; x=1773200127; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OpIrm3j3uJPWqbUKli2gzECKjmYnxa8lu+ueajoi96k=; b=YZ4A2pugP2jVAvTRvbDjERqM9iYHhZGH7bsi1DFiCYU82V5Xj1mvQRmeJxB5dEmTpo Mtbz2GnP6ag+G+G8rQaKJT0+Bf2CmOagKcbXJRQXch6gSGUzgpHLZHS71CBNmAFIn/+G 5pz1lcIjOBuKo8CRVmtLV5XxrKJvWHjGFrTXTwIU+Q/EQooeMWLn2ngAJLrClsYQd/In 2+RuIGVGwjOUtIFAz3g9X1mLbbUR6L6Mb/F/geVpqKS+mpX14OpWKqyn29T6mMWrEz+K Hp0pL66bAGyWL7+C2Ip+x6EHn52/7f00ORAptaVl/DuDPbg0xTJre2JHfl8qp9QtJgnU mLtw== X-Forwarded-Encrypted: i=1; AJvYcCXa3JVIe+IU9BHLvFYh1C7V3UqH3Bl6zsIMKq/Hh4WoZAhWmlMu8wZotnzv3zpGPBi/9T5vTR9loiMkO3U=@vger.kernel.org X-Gm-Message-State: AOJu0Yzu0t0YGRLB7fXmkhTDjZduFcXcViZBoEjkDrvaEJlkubdOpMgb uMC/B3vk4wwHGS8ET+3mpdYBfOYjB9i+517sbCatIKxEn6bYipOGoFYWjIi0Adr1I4Y= X-Gm-Gg: ATEYQzyLcpJhBEm3p+G3b+0DNTEts1vPR/6wfu17C9aXdk1xiitbfwwB0puP8NgksFV isdrV1bR7NPMVuodxHeGUUhNn5N6B/p5CCkKZQs19dZ3Lxmb5Obuw9hUbieIBKbEWvWW/GTvocS ayDtm77Jcr6f142SiasH82/c/1Eucpq6k4fTeK/X+z27Zp8r8lvhgJUt8ZKVWqpmXAoB+qQ3pOa tUHABfE61B2P84jV3AMmfwtfsF7EVSs8IsNjnezzI317s1nL/LBaS63KBoUrVVFGEKBtJh/nj7p SAwy1aearqIbggbNjXI3/2yRdl/ynnxustbqC23AeLmZS597RIu1EfLoJI9CtaFPiOEnhi1oGbm oURnk3DBL5J35YbTFV/EKQUA38mAMGygoiMMkvSyrp9mRFAxwxc3Ruk9f+ZuhIClcfjSWfYuv2T nSR1C414PcuMJmlcbxMSAxZhEBefCXsQMsT1uM6B9yv6VWdMNsfY9gULH2GX3OXdV/me85 X-Received: by 2002:a05:600c:6992:b0:483:6a8d:b2f9 with SMTP id 5b1f17b1804b1-4851984bb31mr8537985e9.5.1772595326542; Tue, 03 Mar 2026 19:35:26 -0800 (PST) Received: from airbuntu (host86-169-41-76.range86-169.btcentralplus.com. [86.169.41.76]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851a7fdb20sm476355e9.0.2026.03.03.19.35.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 19:35:26 -0800 (PST) Date: Wed, 4 Mar 2026 03:35:25 +0000 From: Qais Yousef To: Christian Loehle Cc: Frederic Weisbecker , Thomas Gleixner , LKML , Peter Zijlstra , "Rafael J. Wysocki" Subject: Re: [patch 2/2] sched/idle: Make default_idle_call() NOHZ aware Message-ID: <20260304033525.glcj7d3io57nv3q7@airbuntu> References: <20260301191959.406218221@kernel.org> <20260301192915.171574741@kernel.org> 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=utf-8 Content-Disposition: inline In-Reply-To: On 03/02/26 11:39, Christian Loehle wrote: > 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. I am not sure about all the details, but vm exit seems akin to a deep idle state with sizeable latency hit. Not sure how the power impact can be modeled though.. It seems purely associated with stopping the tick, so maybe can be the same as allowing the physical CPU to enter deep idle state since not stopping the tick means the host cpu can't enter it either? ie: copy min residency from first deep idle state of the host. Haven't thought this through to be honest, but seems there's room for some sensible model. Whether worth it or not, I don't know either :)