From: "Rafael J. Wysocki" <[email protected]>
To: Christian Loehle <[email protected]>
Cc: [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
Srinivas Pandruvada <[email protected]>
Subject: Re: [RFC PATCH 6/8] cpufreq: intel_pstate: Remove iowait boost
Date: Mon, 30 Sep 2024 20:03:45 +0200 [thread overview]
Message-ID: <CAJZ5v0i3ULQ-Mzu=6yzo4whnWne0g1sxcgPL_u828Jyy1Qu1Zg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
+Srinivas who can say more about the reasons why iowait boosting makes
a difference for intel_pstate than I do.
On Thu, Sep 5, 2024 at 11:27 AM Christian Loehle
<[email protected]> wrote:
>
> Analogous to schedutil, remove iowait boost for the same reasons.
Well, first of all, iowait boosting was added to intel_pstate to help
some workloads that otherwise were underperforming. I'm not sure if
you can simply remove it without introducing performance regressions
in those workloads.
While you can argue that it is not useful in schedutil any more due to
the improved scheduler input for it, you can hardly extend that
argument to intel_pstate because it doesn't use all of the scheduler
input used by schedutil.
Also, the EAS and UCLAMP_MAX arguments are not applicable to
intel_pstate because it doesn't support any of them.
This applies to the ondemand cpufreq governor either.
> Signed-off-by: Christian Loehle <[email protected]>
> ---
> drivers/cpufreq/intel_pstate.c | 50 ++--------------------------------
> 1 file changed, 3 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index c0278d023cfc..7f30b2569bb3 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -191,7 +191,6 @@ struct global_params {
> * @policy: CPUFreq policy value
> * @update_util: CPUFreq utility callback information
> * @update_util_set: CPUFreq utility callback is set
> - * @iowait_boost: iowait-related boost fraction
> * @last_update: Time of the last update.
> * @pstate: Stores P state limits for this CPU
> * @vid: Stores VID limits for this CPU
> @@ -245,7 +244,6 @@ struct cpudata {
> struct acpi_processor_performance acpi_perf_data;
> bool valid_pss_table;
> #endif
> - unsigned int iowait_boost;
> s16 epp_powersave;
> s16 epp_policy;
> s16 epp_default;
> @@ -2136,28 +2134,7 @@ static inline void intel_pstate_update_util_hwp_local(struct cpudata *cpu,
> {
> cpu->sample.time = time;
>
> - if (cpu->sched_flags & SCHED_CPUFREQ_IOWAIT) {
> - bool do_io = false;
> -
> - cpu->sched_flags = 0;
> - /*
> - * Set iowait_boost flag and update time. Since IO WAIT flag
> - * is set all the time, we can't just conclude that there is
> - * some IO bound activity is scheduled on this CPU with just
> - * one occurrence. If we receive at least two in two
> - * consecutive ticks, then we treat as boost candidate.
> - */
> - if (time_before64(time, cpu->last_io_update + 2 * TICK_NSEC))
> - do_io = true;
> -
> - cpu->last_io_update = time;
> -
> - if (do_io)
> - intel_pstate_hwp_boost_up(cpu);
> -
> - } else {
> - intel_pstate_hwp_boost_down(cpu);
> - }
> + intel_pstate_hwp_boost_down(cpu);
> }
>
> static inline void intel_pstate_update_util_hwp(struct update_util_data *data,
> @@ -2240,9 +2217,6 @@ static inline int32_t get_target_pstate(struct cpudata *cpu)
> busy_frac = div_fp(sample->mperf << cpu->aperf_mperf_shift,
> sample->tsc);
>
> - if (busy_frac < cpu->iowait_boost)
> - busy_frac = cpu->iowait_boost;
> -
> sample->busy_scaled = busy_frac * 100;
>
> target = READ_ONCE(global.no_turbo) ?
> @@ -2303,7 +2277,7 @@ static void intel_pstate_adjust_pstate(struct cpudata *cpu)
> sample->aperf,
> sample->tsc,
> get_avg_frequency(cpu),
> - fp_toint(cpu->iowait_boost * 100));
> + 0);
> }
>
> static void intel_pstate_update_util(struct update_util_data *data, u64 time,
> @@ -2317,24 +2291,6 @@ static void intel_pstate_update_util(struct update_util_data *data, u64 time,
> return;
>
> delta_ns = time - cpu->last_update;
> - if (flags & SCHED_CPUFREQ_IOWAIT) {
> - /* Start over if the CPU may have been idle. */
> - if (delta_ns > TICK_NSEC) {
> - cpu->iowait_boost = ONE_EIGHTH_FP;
> - } else if (cpu->iowait_boost >= ONE_EIGHTH_FP) {
> - cpu->iowait_boost <<= 1;
> - if (cpu->iowait_boost > int_tofp(1))
> - cpu->iowait_boost = int_tofp(1);
> - } else {
> - cpu->iowait_boost = ONE_EIGHTH_FP;
> - }
> - } else if (cpu->iowait_boost) {
> - /* Clear iowait_boost if the CPU may have been idle. */
> - if (delta_ns > TICK_NSEC)
> - cpu->iowait_boost = 0;
> - else
> - cpu->iowait_boost >>= 1;
> - }
> cpu->last_update = time;
> delta_ns = time - cpu->sample.time;
> if ((s64)delta_ns < INTEL_PSTATE_SAMPLING_INTERVAL)
> @@ -2832,7 +2788,7 @@ static void intel_cpufreq_trace(struct cpudata *cpu, unsigned int trace_type, in
> sample->aperf,
> sample->tsc,
> get_avg_frequency(cpu),
> - fp_toint(cpu->iowait_boost * 100));
> + 0);
> }
>
> static void intel_cpufreq_hwp_update(struct cpudata *cpu, u32 min, u32 max,
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-09-30 18:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 9:26 [RFT RFC PATCH 0/8] cpufreq: cpuidle: Remove iowait behaviour Christian Loehle
2024-09-05 9:26 ` [RFC PATCH 1/8] cpuidle: menu: Remove iowait influence Christian Loehle
2024-09-30 14:58 ` Rafael J. Wysocki
2024-09-05 9:26 ` [RFC PATCH 2/8] cpuidle: Prefer teo over menu governor Christian Loehle
2024-09-30 15:06 ` Rafael J. Wysocki
2024-09-30 16:12 ` Christian Loehle
2024-09-30 16:42 ` Rafael J. Wysocki
2024-09-05 9:26 ` [RFC PATCH 3/8] TEST: cpufreq/schedutil: Linear iowait boost step Christian Loehle
2024-09-05 9:26 ` [RFC PATCH 4/8] TEST: cpufreq/schedutil: iowait boost cap sysfs Christian Loehle
2024-09-05 9:26 ` [RFC PATCH 5/8] cpufreq/schedutil: Remove iowait boost Christian Loehle
2024-09-30 16:34 ` Rafael J. Wysocki
2024-10-03 9:10 ` Christian Loehle
2024-10-03 9:47 ` Quentin Perret
2024-10-03 10:30 ` Christian Loehle
2024-10-05 0:39 ` Andres Freund
2024-10-09 9:54 ` Christian Loehle
2024-09-05 9:26 ` [RFC PATCH 6/8] cpufreq: intel_pstate: " Christian Loehle
2024-09-12 11:22 ` [RFC PATCH] TEST: cpufreq: intel_pstate: sysfs iowait_boost_cap Christian Loehle
2024-09-30 18:03 ` Rafael J. Wysocki [this message]
2024-09-30 20:35 ` [RFC PATCH 6/8] cpufreq: intel_pstate: Remove iowait boost srinivas pandruvada
2024-10-01 9:57 ` Christian Loehle
2024-10-01 14:46 ` srinivas pandruvada
2024-09-05 9:26 ` [RFC PATCH 7/8] cpufreq: Remove SCHED_CPUFREQ_IOWAIT update Christian Loehle
2024-09-05 9:26 ` [RFC PATCH 8/8] io_uring: Do not set iowait before sleeping Christian Loehle
2024-09-05 12:31 ` [RFT RFC PATCH 0/8] cpufreq: cpuidle: Remove iowait behaviour Christian Loehle
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='CAJZ5v0i3ULQ-Mzu=6yzo4whnWne0g1sxcgPL_u828Jyy1Qu1Zg@mail.gmail.com' \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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