mirror of https://lore.kernel.org/lkml/
 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 6/9] cpuidle: teo: Simplify counting events used for tick management
Date: Mon, 13 Jan 2025 19:45:50 +0100	[thread overview]
Message-ID: <1987985.PYKUYFuaPT@rjwysocki.net> (raw)
In-Reply-To: <6116275.lOV4Wx5bFT@rjwysocki.net>

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

Replace the tick_hits metric with a new tick_intercepts one that can be
used directly when deciding whether or not to stop the scheduler tick
and update the governor functional description accordingly.

No intentional functional impact.

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

--- a/drivers/cpuidle/governors/teo.c
+++ b/drivers/cpuidle/governors/teo.c
@@ -41,11 +41,7 @@
  * idle state 2, the third bin spans from the target residency of idle state 2
  * up to, but not including, the target residency of idle state 3 and so on.
  * The last bin spans from the target residency of the deepest idle state
- * supplied by the driver to the scheduler tick period length or to infinity if
- * the tick period length is less than the targer residency of that state.  In
- * the latter case, the governor also counts events with the measured idle
- * duration between the tick period length and the target residency of the
- * deepest idle state.
+ * supplied by the driver to infinity.
  *
  * Two metrics called "hits" and "intercepts" are associated with each bin.
  * They are updated every time before selecting an idle state for the given CPU
@@ -60,6 +56,10 @@
  * into by the sleep length (these events are also referred to as "intercepts"
  * below).
  *
+ * The governor also counts "intercepts" with the measured idle duration below
+ * the tick period length and uses this information when deciding whether or not
+ * to stop the scheduler tick.
+ *
  * In order to select an idle state for a CPU, the governor takes the following
  * steps (modulo the possible latency constraint that must be taken into account
  * too):
@@ -128,14 +128,14 @@
  * @sleep_length_ns: Time till the closest timer event (at the selection time).
  * @state_bins: Idle state data bins for this CPU.
  * @total: Grand total of the "intercepts" and "hits" metrics for all bins.
- * @tick_hits: Number of "hits" after TICK_NSEC.
+ * @tick_intercepts: "Intercepts" before TICK_NSEC.
  */
 struct teo_cpu {
 	s64 time_span_ns;
 	s64 sleep_length_ns;
 	struct teo_bin state_bins[CPUIDLE_STATE_MAX];
 	unsigned int total;
-	unsigned int tick_hits;
+	unsigned int tick_intercepts;
 };
 
 static DEFINE_PER_CPU(struct teo_cpu, teo_cpus);
@@ -207,38 +207,21 @@
 		}
 	}
 
-	/*
-	 * If the deepest state's target residency is below the tick length,
-	 * make a record of it to help teo_select() decide whether or not
-	 * to stop the tick.  This effectively adds an extra hits-only bin
-	 * beyond the last state-related one.
-	 */
-	if (target_residency_ns < TICK_NSEC) {
-		cpu_data->tick_hits -= cpu_data->tick_hits >> DECAY_SHIFT;
-
-		cpu_data->total += cpu_data->tick_hits;
-
-		if (TICK_NSEC <= cpu_data->sleep_length_ns) {
-			idx_timer = drv->state_count;
-			if (TICK_NSEC <= measured_ns) {
-				cpu_data->tick_hits += PULSE;
-				goto end;
-			}
-		}
-	}
-
+	cpu_data->tick_intercepts -= cpu_data->tick_intercepts >> DECAY_SHIFT;
 	/*
 	 * If the measured idle duration falls into the same bin as the sleep
 	 * length, this is a "hit", so update the "hits" metric for that bin.
 	 * Otherwise, update the "intercepts" metric for the bin fallen into by
 	 * the measured idle duration.
 	 */
-	if (idx_timer == idx_duration)
+	if (idx_timer == idx_duration) {
 		cpu_data->state_bins[idx_timer].hits += PULSE;
-	else
+	} else {
 		cpu_data->state_bins[idx_duration].intercepts += PULSE;
+		if (TICK_NSEC <= measured_ns)
+			cpu_data->tick_intercepts += PULSE;
+	}
 
-end:
 	cpu_data->total += PULSE;
 }
 
@@ -286,7 +269,6 @@
 	struct teo_cpu *cpu_data = per_cpu_ptr(&teo_cpus, dev->cpu);
 	s64 latency_req = cpuidle_governor_latency_req(dev->cpu);
 	ktime_t delta_tick = TICK_NSEC / 2;
-	unsigned int tick_intercept_sum = 0;
 	unsigned int idx_intercept_sum = 0;
 	unsigned int intercept_sum = 0;
 	unsigned int idx_hit_sum = 0;
@@ -365,9 +347,6 @@
 		goto end;
 	}
 
-	tick_intercept_sum = intercept_sum +
-			cpu_data->state_bins[drv->state_count-1].intercepts;
-
 	/*
 	 * If the sum of the intercepts metric for all of the idle states
 	 * shallower than the current candidate one (idx) is greater than the
@@ -477,7 +456,7 @@
 	 * total wakeup events, do not stop the tick.
 	 */
 	if (drv->states[idx].target_residency_ns < TICK_NSEC &&
-	    tick_intercept_sum > cpu_data->total / 2 + cpu_data->total / 8)
+	    cpu_data->tick_intercepts > cpu_data->total / 2 + cpu_data->total / 8)
 		duration_ns = TICK_NSEC / 2;
 
 end:




  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 ` [PATCH v1 5/9] cpuidle: teo: Clarify two code comments Rafael J. Wysocki
2025-01-15 19:43   ` Christian Loehle
2025-01-13 18:45 ` Rafael J. Wysocki [this message]
2025-01-20 11:27   ` [PATCH v1 6/9] cpuidle: teo: Simplify counting events used for tick management 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=1987985.PYKUYFuaPT@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

all inboxes | Powered by JetHome®