linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"v4 . 18+" <stable@vger.kernel.org>,
	Doug Smythies <doug.smythies@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 1/2] cpufreq: schedutil: Don't skip freq update when limits change
Date: Fri, 2 Aug 2019 11:11:55 +0200	[thread overview]
Message-ID: <CAJZ5v0g=zXWps29EiFJBPozyw4b9z0YOhtU-UV6hfyu8NbVKNw@mail.gmail.com> (raw)
In-Reply-To: <7dedb6bd157b8183c693bb578e25e313cf4f451d.1564724511.git.viresh.kumar@linaro.org>

On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> To avoid reducing the frequency of a CPU prematurely, we skip reducing
> the frequency if the CPU had been busy recently.
>
> This should not be done when the limits of the policy are changed, for
> example due to thermal throttling. We should always get the frequency
> within the new limits as soon as possible.
>
> Trying to fix this by using only one flag, i.e. need_freq_update, can
> lead to a race condition where the flag gets cleared without forcing us
> to change the frequency at least once. And so this patch introduces
> another flag to avoid that race condition.
>
> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> Cc: v4.18+ <stable@vger.kernel.org> # v4.18+
> Reported-by: Doug Smythies <doug.smythies@gmail.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V2->V3:
> - Updated commit log.
>
> V1->V2:
> - Fixed the race condition using a different flag.
>
> @Doug: I haven't changed the code since you last tested these. Your
> Tested-by tag can be useful while applying the patches. Thanks.
>
>  kernel/sched/cpufreq_schedutil.c | 17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 636ca6f88c8e..2f382b0959e5 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -40,6 +40,7 @@ struct sugov_policy {
>         struct task_struct      *thread;
>         bool                    work_in_progress;
>
> +       bool                    limits_changed;
>         bool                    need_freq_update;
>  };
>
> @@ -89,8 +90,11 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
>             !cpufreq_this_cpu_can_update(sg_policy->policy))
>                 return false;
>
> -       if (unlikely(sg_policy->need_freq_update))
> +       if (unlikely(sg_policy->limits_changed)) {
> +               sg_policy->limits_changed = false;
> +               sg_policy->need_freq_update = true;
>                 return true;
> +       }
>
>         delta_ns = time - sg_policy->last_freq_update_time;
>
> @@ -437,7 +441,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) { return false; }
>  static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct sugov_policy *sg_policy)
>  {
>         if (cpu_bw_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->bw_dl)
> -               sg_policy->need_freq_update = true;
> +               sg_policy->limits_changed = true;
>  }
>
>  static void sugov_update_single(struct update_util_data *hook, u64 time,
> @@ -447,7 +451,7 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
>         struct sugov_policy *sg_policy = sg_cpu->sg_policy;
>         unsigned long util, max;
>         unsigned int next_f;
> -       bool busy;
> +       bool busy = false;

This shouldn't be necessary ->

>
>         sugov_iowait_boost(sg_cpu, time, flags);
>         sg_cpu->last_update = time;
> @@ -457,7 +461,9 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
>         if (!sugov_should_update_freq(sg_policy, time))
>                 return;
>
> -       busy = sugov_cpu_is_busy(sg_cpu);
> +       /* Limits may have changed, don't skip frequency update */
> +       if (!sg_policy->need_freq_update)
> +               busy = sugov_cpu_is_busy(sg_cpu);

-> if this is rewritten as

busy = !sg_policy->need_freq_update && sugov_cpu_is_busy(sg_cpu);

which is simpler and avoids the extra branch.


>
>         util = sugov_get_util(sg_cpu);
>         max = sg_cpu->max;
> @@ -831,6 +837,7 @@ static int sugov_start(struct cpufreq_policy *policy)
>         sg_policy->last_freq_update_time        = 0;
>         sg_policy->next_freq                    = 0;
>         sg_policy->work_in_progress             = false;
> +       sg_policy->limits_changed               = false;
>         sg_policy->need_freq_update             = false;
>         sg_policy->cached_raw_freq              = 0;
>
> @@ -879,7 +886,7 @@ static void sugov_limits(struct cpufreq_policy *policy)
>                 mutex_unlock(&sg_policy->work_lock);
>         }
>
> -       sg_policy->need_freq_update = true;
> +       sg_policy->limits_changed = true;
>  }
>
>  struct cpufreq_governor schedutil_gov = {
> --
> 2.21.0.rc0.269.g1a574e7a288b
>

  parent reply	other threads:[~2019-08-02  9:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02  5:44 Viresh Kumar
2019-08-02  5:44 ` [PATCH V3 2/2] cpufreq: intel_pstate: Implement ->resolve_freq() Viresh Kumar
2019-08-02  9:17   ` Rafael J. Wysocki
2019-08-02  9:28     ` Rafael J. Wysocki
2019-08-03 15:00       ` Doug Smythies
2019-08-05  8:35         ` Rafael J. Wysocki
2019-08-06  4:10       ` Viresh Kumar
2019-08-06  8:05         ` Rafael J. Wysocki
2019-08-02  9:11 ` Rafael J. Wysocki [this message]
2019-08-03  0:00   ` [PATCH V3 1/2] cpufreq: schedutil: Don't skip freq update when limits change Doug Smythies

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='CAJZ5v0g=zXWps29EiFJBPozyw4b9z0YOhtU-UV6hfyu8NbVKNw@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=doug.smythies@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=stable@vger.kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --subject='Re: [PATCH V3 1/2] cpufreq: schedutil: Don'\''t skip freq update when limits change' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).