mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Doug Smythies <dsmythies@telus.net>
Subject: Re: [PATCH v3 1/2] cpuidle: governors: teo: Adjust the classification of wakeup events
Date: Fri, 30 Jan 2026 10:34:20 +0000	[thread overview]
Message-ID: <98b986a8-f44a-46b4-86d2-0bc747206f2d@arm.com> (raw)
In-Reply-To: <5093379.31r3eYUQgx@rafael.j.wysocki>

On 1/29/26 20:49, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If differences between target residency values of adjacent idle states
> of a given CPU are relatively large, the corresponding idle state bins
> used by the teo governors are large either and the rule by which hits
> are distinguished from intercepts is inaccurate.
> 
> Namely, by that rule, a wakeup event is classified as a hit if the
> sleep length (the time till the closest timer other than the tick)
> and the measured idle duration, adjusted for the entered idle state
> exit latency, fall into the same idle state bin.  However, if that bin
> is large enough, the actual difference between the sleep length and
> the measured idle duration may be significant.  It may in fact be
> significantly greater than the analogous difference for an event where
> the sleep length and the measured idle duration fall into different
> bins.
> 
> For this reason, amend the rule in question with a check that will only
> allow a wakeup event to be counted as a hit if the sleep length is less
> than the "raw" measured idle duration (which means that the wakeup
> appears to have occurred after the anticipated timer event).  Otherwise,
> the event will be counted as an intercept.
> 
> Also update the documentation part explaining the difference between
> "hits" and "intercepts" to take the above change into account.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Reviewed-by: Christian Loehle <christian.loehle@arm.com>

> ---
> 
> v2 -> v3:
>    * Use 1/2 of the entered state exit latency instead of a constant
>      margin in the inequality driving the classification (Christian).
>    * Update code comments and the changelog.
> 
> v1.1 -> v2: No changes
> 
> v1 -> v1.1
>    * Drop the change in teo_select() along with the corresponding
>      part of the changelog (after receiving testing feedback from
>      Christian)
> 
> ---
>  drivers/cpuidle/governors/teo.c |   25 ++++++++++++++-----------
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -48,12 +48,11 @@
>   * in accordance with what happened last time.
>   *
>   * The "hits" metric reflects the relative frequency of situations in which the
> - * sleep length and the idle duration measured after CPU wakeup fall into the
> - * same bin (that is, the CPU appears to wake up "on time" relative to the sleep
> - * length).  In turn, the "intercepts" metric reflects the relative frequency of
> - * non-timer wakeup events for which the measured idle duration falls into a bin
> - * that corresponds to an idle state shallower than the one whose bin is fallen
> - * into by the sleep length (these events are also referred to as "intercepts"
> + * sleep length and the idle duration measured after CPU wakeup are close enough
> + * (that is, the CPU appears to wake up "on time" relative to the sleep length).
> + * In turn, the "intercepts" metric reflects the relative frequency of non-timer
> + * wakeup events for which the measured idle duration is significantly different
> + * from the sleep length (these events are also referred to as "intercepts"
>   * below).
>   *
>   * The governor also counts "intercepts" with the measured idle duration below
> @@ -167,6 +166,7 @@ static void teo_decay(unsigned int *metr
>   */
>  static void teo_update(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>  {
> +	s64 lat_ns = drv->states[dev->last_state_idx].exit_latency_ns;
>  	struct teo_cpu *cpu_data = this_cpu_ptr(&teo_cpus);
>  	int i, idx_timer = 0, idx_duration = 0;
>  	s64 target_residency_ns, measured_ns;
> @@ -182,8 +182,6 @@ static void teo_update(struct cpuidle_dr
>  		 */
>  		measured_ns = S64_MAX;
>  	} else {
> -		s64 lat_ns = drv->states[dev->last_state_idx].exit_latency_ns;
> -
>  		measured_ns = dev->last_residency_ns;
>  		/*
>  		 * The delay between the wakeup and the first instruction
> @@ -253,12 +251,17 @@ static void teo_update(struct cpuidle_dr
>  	}
>  
>  	/*
> -	 * 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.
> +	 * If the measured idle duration (adjusted for the entered state exit
> +	 * latency) falls into the same bin as the sleep length and the latter
> +	 * is less than the "raw" measured idle duration (so the wakeup appears
> +	 * to have occurred after the anticipated timer event), 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->sleep_length_ns - measured_ns < lat_ns / 2) {
>  		cpu_data->state_bins[idx_timer].hits += PULSE;
>  	} else {
>  		cpu_data->state_bins[idx_duration].intercepts += PULSE;
> 
> 
> 


  reply	other threads:[~2026-01-30 10:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 20:46 [PATCH v3 0/2] cpuidle: governors: teo: Wakeup events classification change and refinement Rafael J. Wysocki
2026-01-29 20:49 ` [PATCH v3 1/2] cpuidle: governors: teo: Adjust the classification of wakeup events Rafael J. Wysocki
2026-01-30 10:34   ` Christian Loehle [this message]
2026-01-29 20:51 ` [PATCH v3 2/2] cpuidle: governors: teo: Refine intercepts-based idle state lookup Rafael J. Wysocki
2026-01-30 11:04   ` Christian Loehle
2026-01-30 17:58     ` 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=98b986a8-f44a-46b4-86d2-0bc747206f2d@arm.com \
    --to=christian.loehle@arm.com \
    --cc=dsmythies@telus.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@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®