linux-kernel - RE: [PATCH v1 0/2] cpuidle: teo: Refine handling of short idle intervals

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <000f01dba95c$d0504b10$70f0e130$@telus.net>
Date: Wed, 9 Apr 2025 07:36:42 -0700
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Rafael J. Wysocki'" <rjw@...ysocki.net>
Cc: "'LKML'" <linux-kernel@...r.kernel.org>,
	"'Daniel Lezcano'" <daniel.lezcano@...aro.org>,
	"'Christian Loehle'" <christian.loehle@....com>,
	"'Artem Bityutskiy'" <artem.bityutskiy@...ux.intel.com>,
	"'Aboorva Devarajan'" <aboorvad@...ux.ibm.com>,
	"'Linux PM'" <linux-pm@...r.kernel.org>,
	"Doug Smythies" <dsmythies@...us.net>
Subject: RE: [PATCH v1 0/2] cpuidle: teo: Refine handling of short idle intervals

On 2025.04.03 12:16 Rafael J. Wysocki wrote:

> Hi Everyone,

Hi Rafael,

> This series is intended to address an issue with overly aggressive selection
> of idle state 0 (the polling state) in teo on x86 in some cases when timer
> wakeups dominate the CPU wakeup pattern.
>
> In those cases, timer wakeups are not taken into account when they are
> within the LATENCY_THRESHOLD_NS range and the idle state selection may
> be based entirely on non-timer wakeups which may be rare.  This causes
> the prediction accuracy to be low and too much energy may be used as
> a result.
>
> The first patch is preparatory and it is not expected to make any
> functional difference.
>
> The second patch causes teo to take timer wakeups into account if it
> is about to skip the tick_nohz_get_sleep_length() invocation, so they
> get a chance to influence the idle state selection.
>
> I have been using this series on my systems for several weeks and observed
> a significant reduction of the polling state selection rate in multiple
> workloads.

I ran many tests on this patch set.
In general, there is nothing significant to report.

There seemed to be a little less power use for the adrestia test and it took a little longer to execute, but the average wakeup latency was the same.

I am still having noise and repeatability issues with my main periodic tests, where CPU is swept from low to high at serveral work sleep frequencies.
But I didn't observe anything significant.

In order to use more shallow idle states with a periodic workflow, I launched 2000 threads with each at 113 Hertz work/sleep frequency and almost no work to do for each work packet.
The patched version used between 1 and 1.5 less processor package power, at around 85 watts.
The patched version spent about 3.5% in idle state 0 verses about 5% for the unpatched version.
The patched version spent about 31.8% in idle state 1 verses about 30.2% for the unpatched version.

Test computer:
Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz
Distro: Ubuntu 24.04.1, server, no desktop GUI.
CPU frequency scaling driver: intel_pstate
HWP: disabled.
CPU frequency scaling governor: performance
Ilde driver: intel_idle
Idle governor: teo
Idle states: 4: name : description:
  state0/name:POLL                desc:CPUIDLE CORE POLL IDLE
  state1/name:C1_ACPI          desc:ACPI FFH MWAIT 0x0
  state2/name:C2_ACPI          desc:ACPI FFH MWAIT 0x30
  state3/name:C3_ACPI          desc:ACPI FFH MWAIT 0x60

... Doug