public inbox for linux-kernel@vger.kernel.org
 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>
Subject: [PATCH v1 5/9] cpuidle: teo: Clarify two code comments
Date: Mon, 13 Jan 2025 19:41:55 +0100	[thread overview]
Message-ID: <8472971.T7Z3S40VBb@rjwysocki.net> (raw)
In-Reply-To: <6116275.lOV4Wx5bFT@rjwysocki.net>

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Rewrite two code comments suposed to explain its behavior that are too
concise or not sufficiently clear.

No functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpuidle/governors/teo.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

--- a/drivers/cpuidle/governors/teo.c
+++ b/drivers/cpuidle/governors/teo.c
@@ -154,9 +154,10 @@
 
 	if (cpu_data->time_span_ns >= cpu_data->sleep_length_ns) {
 		/*
-		 * One of the safety nets has triggered or the wakeup was close
-		 * enough to the closest timer event expected at the idle state
-		 * selection time to be discarded.
+		 * This causes the wakeup to be counted as a hit regardless of
+		 * regardless of the real idle duration which doesn't need to be
+		 * computed because the wakeup has been close enough to an
+		 * anticipated timer.
 		 */
 		measured_ns = U64_MAX;
 	} else {
@@ -302,8 +303,13 @@
 
 	cpu_data->time_span_ns = local_clock();
 	/*
-	 * Set the expected sleep length to infinity in case of an early
-	 * return.
+	 * Set the sleep length to infitity in case the invocation of
+	 * tick_nohz_get_sleep_length() below is skipped, in which case it won't
+	 * be known whether or not the subsequent wakeup is caused by a timer.
+	 * It is generally fine to count the wakeup as an intercept then, except
+	 * for the cases when the CPU is mostly woken up by timers and there may
+	 * be opportunities to ask for a deeper idle state when no imminent
+	 * timers are scheduled which may be missed.
 	 */
 	cpu_data->sleep_length_ns = KTIME_MAX;
 




  parent reply	other threads:[~2025-01-13 18:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 18:32 [PATCH v1 0/9] cpuidle: teo: Cleanups and very frequent wakeups handling update Rafael J. Wysocki
2025-01-13 18:34 ` [PATCH v1 1/9] cpuidle: teo: Rearrange idle state lookup code Rafael J. Wysocki
2025-01-15 14:21   ` Christian Loehle
2025-01-13 18:36 ` [PATCH v1 2/9] cpuidle: teo: Reorder candidate state index checks Rafael J. Wysocki
2025-01-15 14:46   ` Christian Loehle
2025-01-15 15:54     ` Rafael J. Wysocki
2025-01-15 19:20       ` Christian Loehle
2025-01-15 20:48         ` Rafael J. Wysocki
2025-01-15 21:10           ` Rafael J. Wysocki
2025-01-16 12:22             ` Rafael J. Wysocki
2025-01-16 13:26               ` Christian Loehle
2025-01-16 13:27   ` Christian Loehle
2025-01-13 18:39 ` [PATCH v1 3/9] cpuidle: teo: Combine candidate state index checks against 0 Rafael J. Wysocki
2025-01-15 19:44   ` Christian Loehle
2025-01-13 18:40 ` [PATCH v1 4/9] cpuidle: teo: Drop local variable prev_intercept_idx Rafael J. Wysocki
2025-01-15 19:46   ` Christian Loehle
2025-01-13 18:41 ` Rafael J. Wysocki [this message]
2025-01-15 19:43   ` [PATCH v1 5/9] cpuidle: teo: Clarify two code comments Christian Loehle
2025-01-13 18:45 ` [PATCH v1 6/9] cpuidle: teo: Simplify counting events used for tick management Rafael J. Wysocki
2025-01-20 11:27   ` Christian Loehle
2025-01-13 18:48 ` [PATCH v1 7/9] cpuidle: teo: Skip getting the sleep length is wakeups are very frequent Rafael J. Wysocki
2025-01-20 12:08   ` Christian Loehle
2025-01-20 16:24     ` Rafael J. Wysocki
2025-01-13 18:50 ` [PATCH v1 8/9] cpuidle: teo: Simplify handling of total events count Rafael J. Wysocki
2025-01-20 12:10   ` Christian Loehle
2025-01-13 18:51 ` [PATCH v1 9/9] cpuidle: teo: Replace time_span_ns with a flag Rafael J. Wysocki
2025-01-20 12:16   ` Christian Loehle
2025-01-20 12:42     ` Rafael J. Wysocki
2025-01-15 14:52 ` [PATCH v1 0/9] cpuidle: teo: Cleanups and very frequent wakeups handling update Christian Loehle
2025-01-20  8:17   ` Aboorva Devarajan
2025-01-20 16:26     ` Rafael J. Wysocki
2025-01-20 16:24   ` Rafael J. Wysocki

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=8472971.T7Z3S40VBb@rjwysocki.net \
    --to=rjw@rjwysocki.net \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=christian.loehle@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --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