From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f44.google.com (mail-dl1-f44.google.com [74.125.82.44]) (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 4E31437754D for ; Thu, 5 Mar 2026 17:09:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772730581; cv=none; b=gksGzOvjEZN4gzeW1Z+PSIk+yoK3d6+Rr+a41GhGMHlNMbx2cYqddnQS/W9XYkUk3VI1QRJxeg8FbXiF1F8P8JkzajRdjY02VHapxHBOjzupDCIlMS0h7sJ6f2q/sWmHv9YFzM8gkslFzny+m2IoqQbPDEs6YVrOPgHms9Ft3do= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772730581; c=relaxed/simple; bh=QYLm+5Rs5AJwatSWGCk6jd6QWUZZSU4/Nsrh+DKO1SE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C+1VwyXq8XLvwwLrELV4LBKSm5/16+eAAdHJ4qe323v8St3LsatDgo8mYhpAVzWYJi3S5tOIYVEZqYwTXSQKQbhnS1drRDTgFT+5HSnA8hxzerLa7E6XeywY70NArGkfNsx6sRy98BYCL3/0a4Uzxl/+tPrtuc2NJj3SxCqjMdo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lUphhDZz; arc=none smtp.client-ip=74.125.82.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lUphhDZz" Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-1275910b930so5248837c88.0 for ; Thu, 05 Mar 2026 09:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772730579; x=1773335379; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=n0LMTjXkZSK17nahPAopPxOjENVtdK5q1MgyibnZgUE=; b=lUphhDZzOkzwF9M9BE4isfIn299cv1/jjEWFunondJpWNf7llaKdCJckbzVFEWwC2D URUX6ToirYVDu85fWXwGnT+2EsBTLr2BQ8zwwNhaqCwvcwqRU7h58o/hA/vW/q77Wto8 GdcnvQF9jTxf+7bpkP7sVtkWkwf6HDy+tHdhkfBEMHy1b5hwZE2leW+j6SG+l3GJmrjI AwWD07THYOO1za75ljOrirw77uN12q+R8qtGa2pYnRpZafwUsqFjtRD1u8C1lPdNzSMy 0faCKoFO/edYLAW4rbxApFAX99avEUNHuOPXbBd95kLgVD2VecXMWcDn8TRHJCOU5WDB +/Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772730579; x=1773335379; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=n0LMTjXkZSK17nahPAopPxOjENVtdK5q1MgyibnZgUE=; b=EcJTmgSDsaKIlTRHUO3jYQwrh0RGajLVprFzaS3JbjcJbj7sx10jaFTyW9LCXvujcn dVXdjTU5iHymx10E3p7p4NVVTU0rrYNBfKsWLQ9l/Wzt5jjKAtmJGykUsSt1KxmEAMWM /nX1G366n7c98LIWTU4ml32T1iALWiXbmFGWtSH1Vl5F+JDcP61QBu+TIU1Ys/wnx4u/ zPqaLYJrPw7EvJKtFKiDcUk6elSKuxIYtSdAJvRcDSWwF0ghlNt6tNFO3GxIhWkYavS2 yrgsb7WfSg4CSsqtoaEatqME3vCnSgZn9RCMxv498hijDm8WAEpLn75tYgfTNY/BesLT r+hw== X-Forwarded-Encrypted: i=1; AJvYcCWMhD7GPL4+2LrwAUBYaXAfzfFXIhXr4tN6+UJ7qO3J+giOW7vCOoAHH9QyIDeMkQyH4RoBn3RPQV119v8=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1PtH1sVI5JbfTXiXeV7cBopqfmp48ORRQIRNtYv/yvXMWu7yT +IB856gHkZfOA/wdw9CiB2/warkABbN/RWhomXoiIVZMHqingOnL29ex X-Gm-Gg: ATEYQzx56unS22/uB8FRVYOpaFFZXdTzwsviEC7254T9HCq4gCBeBPi5L0DZiijWFqR rk9HHkpQmN11xG+I5wnPpS/+ldrbeGkglkuBcc6pyYM+AqBt4AZabWEk2RvIbXjNIE12i6Enkag +J4GM6gl0MdKrewRg8j1hDCVNWjlMMkqi6RfXKIYaWNHERyAn/c2jMqYHZ+UHTRFd7Ed0zngrC/ Icw3Gz9JoW2eQpdOiYX1CZaobmDQsz0nr2uUthsFrdObGagP7YUPTT5mM8pQ6XX9UcLfeB4n306 bGAEGUbQlznnV8FxOx2q2V6Q9TAr6gooRq49mEdlft1372ncKPkFc7xBbu35TrDTv6RXOjWliWe c1RuNDFrFbHp7TwolibySRG3x5oUuSwLp2d0wGjaPzEUMf9TmqWUxY8Qx4uj48/TmtVEmHDhzct 1wF3MMnDelf3yyZKumsts/Udhpd86vbBBfhDq7 X-Received: by 2002:a05:7022:f8f:b0:128:b534:bd04 with SMTP id a92af1059eb24-128bbfa3ca4mr1138885c88.5.1772730579267; Thu, 05 Mar 2026 09:09:39 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12789a32863sm20676965c88.10.2026.03.05.09.09.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 09:09:38 -0800 (PST) Sender: Guenter Roeck Date: Thu, 5 Mar 2026 09:09:37 -0800 From: Guenter Roeck To: "Rafael J. Wysocki" Cc: Aboorva Devarajan , christian.loehle@arm.com, daniel.lezcano@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/4] cpuidle: Skip governor when only one idle state is available Message-ID: <7f84ebb8-1802-44d4-8b63-1ad026f0baa6@roeck-us.net> References: <20260216185005.1131593-1-aboorvad@linux.ibm.com> <20260216185005.1131593-2-aboorvad@linux.ibm.com> <37ab17cd-0488-44bd-9e03-1ba3c0757e8f@roeck-us.net> 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 Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Mar 05, 2026 at 06:06:53PM +0100, Rafael J. Wysocki wrote: > On Thu, Mar 5, 2026 at 5:53 PM Guenter Roeck wrote: > > > > Hi, > > > > On Tue, Feb 17, 2026 at 12:20:02AM +0530, Aboorva Devarajan wrote: > > > On certain platforms (PowerNV systems without a power-mgt DT node), > > > cpuidle may register only a single idle state. In cases where that > > > single state is a polling state (state 0), the ladder governor may > > > incorrectly treat state 1 as the first usable state and pass an > > > out-of-bounds index. This can lead to a NULL enter callback being > > > invoked, ultimately resulting in a system crash. > > > > > > [ 13.342636] cpuidle-powernv : Only Snooze is available > > > [ 13.351854] Faulting instruction address: 0x00000000 > > > [ 13.376489] NIP [0000000000000000] 0x0 > > > [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 > > > > > > Fix this by adding a bail-out in cpuidle_select() that returns state 0 > > > directly when state_count <= 1, bypassing the governor and keeping the > > > tick running. > > > > > > Fixes: dc2251bf98c6 ("cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol") > > > Signed-off-by: Aboorva Devarajan > > > --- > > > drivers/cpuidle/cpuidle.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c > > > index c7876e9e024f..65fbb8e807b9 100644 > > > --- a/drivers/cpuidle/cpuidle.c > > > +++ b/drivers/cpuidle/cpuidle.c > > > @@ -359,6 +359,16 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev, > > > int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev, > > > bool *stop_tick) > > > { > > > + /* > > > + * If there is only a single idle state (or none), there is nothing > > > + * meaningful for the governor to choose. Skip the governor and > > > + * always use state 0 with the tick running. > > > + */ > > > + if (drv->state_count <= 1) { > > > + *stop_tick = false; > > > + return 0; > > > + } > > > + > > > > An experimental AI review agent provided the following feedback: > > > > Does this unconditionally keep the tick running on systems that only have a > > single non-polling idle state (like basic ARM systems that only support WFI)? > > > > Before this patch, governors like menu would check CPUIDLE_FLAG_POLLING before > > deciding to keep the tick running. Could this change effectively disable > > NO_HZ_IDLE on these systems, causing higher power consumption? > > > > I don't know scheduling well enough to understand if this is a real problem, > > but I thought it is worth mentioning it. > > > > Please let me know if the problem is real or not so I can feed it back into > > the agent. > > On bare metal, this isn't a problem at least in practice because the > only available idle state cannot be too deep anyway, so stopping the > tick doesn't improve energy efficiency too much and it adds overhead. > > On virt, it may be a problem if the tick that runs in the VM > effectively prevents the host from using deep idle states, but that > would only matter for VMs running on systems that have deep enough > idle state in configurations where the VM has only one idle state. > > This is kind of under discussion in a separate thread here: > https://lore.kernel.org/lkml/20260301192915.171574741@kernel.org/#r Thanks a lot for the feedback! Guenter