linux-kernel - Re: [PATCH v1 3/3] cpuidle: governors: menu: Special-case nohz

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260208155902.437740-1-ionut.nechita@windriver.com>
Date: Sun,  8 Feb 2026 17:59:00 +0200
From: "Ionut Nechita (Wind River)" <ionut.nechita@...driver.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Ionut Nechita <ionut.nechita@...driver.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Christian Loehle <christian.loehle@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Ionut Nechita <ionut_n2001@...oo.com>,
        Ionut Nechita <sunlightlinux@...il.com>
Subject: Re: [PATCH v1 3/3] cpuidle: governors: menu: Special-case nohz_full CPUs

Hi Rafael,

I have a question regarding this patch: is it planned for upstream
integration, or is there a newer/improved version in the works?

I'm asking because I've been working on a related optimization in the
same code path. My patch [1] takes a different approach to the same
problem area -- instead of skipping the override entirely for nohz_full
CPUs, it changes:

    predicted_ns = data->next_timer_ns;

to:

    predicted_ns = min(predicted_ns, data->next_timer_ns);

The idea is to prevent selecting excessively deep C-states when the
prediction is short but the next timer is distant, which on platforms
like Sapphire Rapids with high exit latencies (150us+) can cause
significant latency spikes.

I notice that our patches touch the same block but address slightly
different aspects:

- Your patch: prevents the override from firing on nohz_full CPUs
  where tick_stopped is always true, avoiding systematically
  discarding the prediction.
- My patch: when the override does fire, uses min() instead of
  unconditional replacement to preserve information from the
  prediction.

These two fixes could potentially be complementary. However, my patch
is still under investigation due to limited hardware availability for
collecting more data across different platforms.

I'd appreciate your thoughts on whether these approaches could be
combined, or if your patch already addresses the use cases I'm seeing.

Thanks,
Ionut

[1] https://lore.kernel.org/linux-pm/20260122080937.22347-4-sunlightlinux@gmail.com/