Linux Power Management development
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Christian Loehle <christian.loehle@arm.com>,
	Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Doug Smythies <dsmythies@telus.net>,
	Aboorva Devarajan <aboorvad@linux.ibm.com>
Subject: [PATCH v1 0/2] cpuidle: teo: Refine handling of short idle intervals
Date: Thu, 03 Apr 2025 21:16:08 +0200	[thread overview]
Message-ID: <4661520.LvFx2qVVIh@rjwysocki.net> (raw)

Hi Everyone,

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.

Thanks!




             reply	other threads:[~2025-04-03 19:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-03 19:16 Rafael J. Wysocki [this message]
2025-04-03 19:16 ` [PATCH v1 1/2] cpuidle: teo: Move candidate state lookup to separate function Rafael J. Wysocki
2025-04-03 19:18 ` [PATCH v1 2/2] cpuidle: teo: Refine handling of short idle intervals Rafael J. Wysocki
2025-04-16 15:00   ` Christian Loehle
2025-04-16 15:28     ` Rafael J. Wysocki
2025-04-17 11:58       ` Christian Loehle
2025-04-17 15:21         ` Rafael J. Wysocki
2025-04-17 17:18           ` Christian Loehle
2025-04-17 19:05             ` Rafael J. Wysocki
2025-04-09  6:52 ` [PATCH v1 0/2] " Artem Bityutskiy
2025-04-09 12:06   ` Rafael J. Wysocki
2025-04-09 14:36 ` Doug Smythies
2025-04-09 14:41   ` Rafael J. Wysocki
2025-04-14  7:15 ` Aboorva Devarajan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4661520.LvFx2qVVIh@rjwysocki.net \
    --to=rjw@rjwysocki.net \
    --cc=aboorvad@linux.ibm.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=christian.loehle@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dsmythies@telus.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox