All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, sudeep.holla@arm.com,
	gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, viresh.kumar@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-pm@vger.kernel.org, conor.dooley@microchip.com,
	suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH 3/4] cpufreq/schedutil: use a fixed reference frequency
Date: Thu, 21 Sep 2023 10:19:40 +0100	[thread overview]
Message-ID: <ZQwKnnXbjLOYUSjO@arm.com> (raw)
In-Reply-To: <20230901130312.247719-4-vincent.guittot@linaro.org>

On Friday 01 Sep 2023 at 15:03:11 (+0200), Vincent Guittot wrote:
> cpuinfo_max_freq can change at runtime because of boost as example. This
> implies that the value could not be the same than the one that has been
> used when computing the capacity of a CPU.
> 
> The new arch_scale_freq_ref() returns a fixed and coherent frequency
> reference that can be used when computing a frequency based on utilization.
> 
> Use this arch_scale_freq_ref() when available and fallback to
> cpuinfo.max_freq otherwise.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  kernel/sched/cpufreq_schedutil.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 4492608b7d7f..9996ef429e2b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -114,6 +114,31 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  	}
>  }
>  
> +#ifdef arch_scale_freq_ref
> +/**
> + * arch_scale_freq_ref_policy - get the reference frequency of a given CPU that
> + * has been used to correlate frequency and compute capacity.
> + * @cpu: the CPU in question.
> + *
> + * Return: the reference CPU frequency.
> + */
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)

This should not be an arch_ function as it's only a wrapper over an
arch_ function and not a function that different architectures might
implement differently usually in architecture specific code.

> +{
> +	return arch_scale_freq_ref(policy->cpu);

It might make it easier to read if arch_scale_freq_ref() had a default
implementation that returned 0.

Then this code would simply become:

freq = arch_scale_freq_ref(policy->cpu);
if (freq)
	return freq;
else if (arch_scale_freq_invariant())
	return ..
..

This approach is similar to the use of arch_freq_get_on_cpu() in
cpufreq.c, and, as there, having a chosen maximum frequency of 0 would
not be a valid value.

> +}
> +#else
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)
> +{
> +	if (arch_scale_freq_invariant())
> +		return policy->cpuinfo.max_freq;
> +
> +
> +	return policy->cur;
> +}
> +#endif
> +
>  /**
>   * get_next_freq - Compute a new frequency for a given cpufreq policy.
>   * @sg_policy: schedutil policy object to compute the new frequency for.
> @@ -139,11 +164,11 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>  				  unsigned long util, unsigned long max)
>  {
> +	unsigned int freq;
>  	struct cpufreq_policy *policy = sg_policy->policy;
> -	unsigned int freq = arch_scale_freq_invariant() ?
> -				policy->cpuinfo.max_freq : policy->cur;
>  
>  	util = map_util_perf(util);
> +	freq = arch_scale_freq_ref_policy(policy);

Given its single use here, it would likely be better to place the code
above directly here, rather than create a wrapper over a few lines of
code.

Hope it helps,
Ionela.

>  	freq = map_util_freq(util, freq, max);
>  
>  	if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
> -- 
> 2.34.1
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, sudeep.holla@arm.com,
	gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, viresh.kumar@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-pm@vger.kernel.org, conor.dooley@microchip.com,
	suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH 3/4] cpufreq/schedutil: use a fixed reference frequency
Date: Thu, 21 Sep 2023 10:19:40 +0100	[thread overview]
Message-ID: <ZQwKnnXbjLOYUSjO@arm.com> (raw)
In-Reply-To: <20230901130312.247719-4-vincent.guittot@linaro.org>

On Friday 01 Sep 2023 at 15:03:11 (+0200), Vincent Guittot wrote:
> cpuinfo_max_freq can change at runtime because of boost as example. This
> implies that the value could not be the same than the one that has been
> used when computing the capacity of a CPU.
> 
> The new arch_scale_freq_ref() returns a fixed and coherent frequency
> reference that can be used when computing a frequency based on utilization.
> 
> Use this arch_scale_freq_ref() when available and fallback to
> cpuinfo.max_freq otherwise.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  kernel/sched/cpufreq_schedutil.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 4492608b7d7f..9996ef429e2b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -114,6 +114,31 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  	}
>  }
>  
> +#ifdef arch_scale_freq_ref
> +/**
> + * arch_scale_freq_ref_policy - get the reference frequency of a given CPU that
> + * has been used to correlate frequency and compute capacity.
> + * @cpu: the CPU in question.
> + *
> + * Return: the reference CPU frequency.
> + */
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)

This should not be an arch_ function as it's only a wrapper over an
arch_ function and not a function that different architectures might
implement differently usually in architecture specific code.

> +{
> +	return arch_scale_freq_ref(policy->cpu);

It might make it easier to read if arch_scale_freq_ref() had a default
implementation that returned 0.

Then this code would simply become:

freq = arch_scale_freq_ref(policy->cpu);
if (freq)
	return freq;
else if (arch_scale_freq_invariant())
	return ..
..

This approach is similar to the use of arch_freq_get_on_cpu() in
cpufreq.c, and, as there, having a chosen maximum frequency of 0 would
not be a valid value.

> +}
> +#else
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)
> +{
> +	if (arch_scale_freq_invariant())
> +		return policy->cpuinfo.max_freq;
> +
> +
> +	return policy->cur;
> +}
> +#endif
> +
>  /**
>   * get_next_freq - Compute a new frequency for a given cpufreq policy.
>   * @sg_policy: schedutil policy object to compute the new frequency for.
> @@ -139,11 +164,11 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>  				  unsigned long util, unsigned long max)
>  {
> +	unsigned int freq;
>  	struct cpufreq_policy *policy = sg_policy->policy;
> -	unsigned int freq = arch_scale_freq_invariant() ?
> -				policy->cpuinfo.max_freq : policy->cur;
>  
>  	util = map_util_perf(util);
> +	freq = arch_scale_freq_ref_policy(policy);

Given its single use here, it would likely be better to place the code
above directly here, rather than create a wrapper over a few lines of
code.

Hope it helps,
Ionela.

>  	freq = map_util_freq(util, freq, max);
>  
>  	if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
> -- 
> 2.34.1
> 
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, sudeep.holla@arm.com,
	gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, viresh.kumar@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-pm@vger.kernel.org, conor.dooley@microchip.com,
	suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org
Subject: Re: [PATCH 3/4] cpufreq/schedutil: use a fixed reference frequency
Date: Thu, 21 Sep 2023 10:19:40 +0100	[thread overview]
Message-ID: <ZQwKnnXbjLOYUSjO@arm.com> (raw)
In-Reply-To: <20230901130312.247719-4-vincent.guittot@linaro.org>

On Friday 01 Sep 2023 at 15:03:11 (+0200), Vincent Guittot wrote:
> cpuinfo_max_freq can change at runtime because of boost as example. This
> implies that the value could not be the same than the one that has been
> used when computing the capacity of a CPU.
> 
> The new arch_scale_freq_ref() returns a fixed and coherent frequency
> reference that can be used when computing a frequency based on utilization.
> 
> Use this arch_scale_freq_ref() when available and fallback to
> cpuinfo.max_freq otherwise.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  kernel/sched/cpufreq_schedutil.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 4492608b7d7f..9996ef429e2b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -114,6 +114,31 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  	}
>  }
>  
> +#ifdef arch_scale_freq_ref
> +/**
> + * arch_scale_freq_ref_policy - get the reference frequency of a given CPU that
> + * has been used to correlate frequency and compute capacity.
> + * @cpu: the CPU in question.
> + *
> + * Return: the reference CPU frequency.
> + */
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)

This should not be an arch_ function as it's only a wrapper over an
arch_ function and not a function that different architectures might
implement differently usually in architecture specific code.

> +{
> +	return arch_scale_freq_ref(policy->cpu);

It might make it easier to read if arch_scale_freq_ref() had a default
implementation that returned 0.

Then this code would simply become:

freq = arch_scale_freq_ref(policy->cpu);
if (freq)
	return freq;
else if (arch_scale_freq_invariant())
	return ..
..

This approach is similar to the use of arch_freq_get_on_cpu() in
cpufreq.c, and, as there, having a chosen maximum frequency of 0 would
not be a valid value.

> +}
> +#else
> +static __always_inline
> +unsigned long  arch_scale_freq_ref_policy(struct cpufreq_policy *policy)
> +{
> +	if (arch_scale_freq_invariant())
> +		return policy->cpuinfo.max_freq;
> +
> +
> +	return policy->cur;
> +}
> +#endif
> +
>  /**
>   * get_next_freq - Compute a new frequency for a given cpufreq policy.
>   * @sg_policy: schedutil policy object to compute the new frequency for.
> @@ -139,11 +164,11 @@ static void sugov_deferred_update(struct sugov_policy *sg_policy)
>  static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>  				  unsigned long util, unsigned long max)
>  {
> +	unsigned int freq;
>  	struct cpufreq_policy *policy = sg_policy->policy;
> -	unsigned int freq = arch_scale_freq_invariant() ?
> -				policy->cpuinfo.max_freq : policy->cur;
>  
>  	util = map_util_perf(util);
> +	freq = arch_scale_freq_ref_policy(policy);

Given its single use here, it would likely be better to place the code
above directly here, rather than create a wrapper over a few lines of
code.

Hope it helps,
Ionela.

>  	freq = map_util_freq(util, freq, max);
>  
>  	if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
> -- 
> 2.34.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-09-21 18:15 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01 13:03 [PATCH 0/4] consolidate and cleanup CPU capacity Vincent Guittot
2023-09-01 13:03 ` Vincent Guittot
2023-09-01 13:03 ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 1/4] sched: consolidate and cleanup access to CPU's max compute capacity Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-05 11:25   ` Peter Zijlstra
2023-09-05 11:25     ` Peter Zijlstra
2023-09-05 11:25     ` Peter Zijlstra
2023-09-14 20:45   ` Dietmar Eggemann
2023-09-14 20:45     ` Dietmar Eggemann
2023-09-14 20:45     ` Dietmar Eggemann
2023-09-15 13:20     ` Vincent Guittot
2023-09-15 13:20       ` Vincent Guittot
2023-09-15 13:20       ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 2/4] topology: add a new arch_scale_freq_reference Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-04 12:35   ` Lukasz Luba
2023-09-04 12:35     ` Lukasz Luba
2023-09-04 12:35     ` Lukasz Luba
2023-09-18 11:23     ` Vincent Guittot
2023-09-18 11:23       ` Vincent Guittot
2023-09-18 11:23       ` Vincent Guittot
2023-09-14 21:01   ` Dietmar Eggemann
2023-09-14 21:01     ` Dietmar Eggemann
2023-09-14 21:01     ` Dietmar Eggemann
2023-09-21  9:00   ` Ionela Voinescu
2023-09-21  9:00     ` Ionela Voinescu
2023-09-21  9:00     ` Ionela Voinescu
2023-09-25 12:06     ` Vincent Guittot
2023-09-25 12:06       ` Vincent Guittot
2023-09-25 12:06       ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 3/4] cpufreq/schedutil: use a fixed reference frequency Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-02 10:57   ` Conor Dooley
2023-09-02 10:57     ` Conor Dooley
2023-09-02 10:57     ` Conor Dooley
2023-09-02 12:49     ` Vincent Guittot
2023-09-02 12:49       ` Vincent Guittot
2023-09-02 12:49       ` Vincent Guittot
2023-09-05 11:24   ` Peter Zijlstra
2023-09-05 11:24     ` Peter Zijlstra
2023-09-05 11:24     ` Peter Zijlstra
2023-09-05 13:50     ` Vincent Guittot
2023-09-05 13:50       ` Vincent Guittot
2023-09-05 13:50       ` Vincent Guittot
2023-09-21  9:19   ` Ionela Voinescu [this message]
2023-09-21  9:19     ` Ionela Voinescu
2023-09-21  9:19     ` Ionela Voinescu
2023-09-25 12:06     ` Vincent Guittot
2023-09-25 12:06       ` Vincent Guittot
2023-09-25 12:06       ` Vincent Guittot
2023-09-01 13:03 ` [PATCH 4/4] energy_model: " Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-01 13:03   ` Vincent Guittot
2023-09-04 12:40   ` Lukasz Luba
2023-09-04 12:40     ` Lukasz Luba
2023-09-04 12:40     ` Lukasz Luba
2023-09-05 10:05   ` Pierre Gondois
2023-09-05 10:05     ` Pierre Gondois
2023-09-05 10:05     ` Pierre Gondois
2023-09-05 11:33     ` Peter Zijlstra
2023-09-05 11:33       ` Peter Zijlstra
2023-09-05 11:33       ` Peter Zijlstra
2023-09-05 13:16     ` Vincent Guittot
2023-09-05 13:16       ` Vincent Guittot
2023-09-05 13:16       ` Vincent Guittot
2023-09-14 21:07   ` Dietmar Eggemann
2023-09-14 21:07     ` Dietmar Eggemann
2023-09-14 21:07     ` Dietmar Eggemann
2023-09-15 13:35     ` Vincent Guittot
2023-09-15 13:35       ` Vincent Guittot
2023-09-15 13:35       ` Vincent Guittot
2023-09-18 20:46       ` Dietmar Eggemann
2023-09-18 20:46         ` Dietmar Eggemann
2023-09-18 20:46         ` Dietmar Eggemann
2023-09-21 10:12   ` Ionela Voinescu
2023-09-21 10:12     ` Ionela Voinescu
2023-09-21 10:12     ` Ionela Voinescu
2023-09-21 10:12 ` [PATCH 0/4] consolidate and cleanup CPU capacity Ionela Voinescu
2023-09-21 10:12   ` Ionela Voinescu
2023-09-21 10:12   ` Ionela Voinescu
2023-09-25 12:05   ` Vincent Guittot
2023-09-25 12:05     ` Vincent Guittot
2023-09-25 12:05     ` Vincent Guittot

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=ZQwKnnXbjLOYUSjO@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor.dooley@microchip.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=juri.lelli@redhat.com \
    --cc=lftan@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=suagrfillet@gmail.com \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.