Re: [PATCH] x86/cpuidle: split the max_cstate variable

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.04.2026 23:11, Marek Marczykowski wrote:
> On Wed, Apr 08, 2026 at 01:34:43PM +0200, Jan Beulich wrote:
>> The admin can control the upper bound wanted not only via command line
>> option, but also via XEN_SYSCTL_pm_op_set_max_cstate. While decisions how
>> to set up the system are okay this way as long as we deem the command line
>> option a strict upper bound, what to do during S3 resume should not be
>> based on that potentially varying value. Decisions there need to use
>> solely the strict upper bound we may have enforced ourselves (or which was
>> forced onto us via command line option).
>>
>> Rather than altering pit_broadcast_is_available(), drop the function
>> altogether. It's pretty odd for acpi/cpu_idle.c to call into time.c, just
>> for that to call into acpi/cpu_idle.c again.
>>
>> Fixes: 8d24303023ec ("x86: don't write_tsc() non-zero values on CPUs 
>> updating only the lower 32 bits")
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> What should be observable effect, in absence of max_cstate option and
> "xenpm set-max-cstate" calls?

None. Only if you lower max C-state before S3 to then raise it again
afterwards.

> The "slow after S3" issue still happens. I
> tested this on top of the two other patches:
> - [PATCH] x86/HPET: channel handling in hpet_broadcast_resume()
> - [PATCH] x86/cpu-policy: set up host policy earlier

Right, nothing else was expected. I Cc-ed you because the issue is S3-related
(and you are who primarily uses that) and because I noticed the issue here
while trying to figure out your actual problems.

>> ---
>> cpuidle_disable_deep_cstate(), when called from handle_rtc_once(), is
>> still somewhat of a problem: Boot time and resume time runs of
>> _disable_pit_irq() may still behave differently because of that.
> 
> In the above test, both on boot and resume I got:
> (XEN) [    9.916522] _disable_pit_irq:2649: using_pit: 0, cpu_has_apic: 1
> (XEN) [    9.921198] _disable_pit_irq:2659: cpuidle_usable_deep_cstate: 1, 
> boot_cpu_has(X86_FEATURE_XEN_ARAT): 1

I don't expect handle_rtc_once() was involved, though?

Jan