linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Bellasi <patrick.bellasi@arm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	John Stultz <john.stultz@linaro.org>,
	Juri Lelli <juri.lelli@arm.com>, Todd Kjos <tkjos@android.com>,
	Tim Murray <timmurray@google.com>,
	Andres Oportus <andresoportus@google.com>,
	Joel Fernandes <joelaf@google.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Chris Redpath <chris.redpath@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
Date: Fri, 7 Apr 2017 15:59:09 +0100	[thread overview]
Message-ID: <20170407145909.GD29455@e110439-lin> (raw)
In-Reply-To: <1642681.8y9FrPCKVW@aspire.rjw.lan>

On 29-Mar 00:18, Rafael J. Wysocki wrote:
> On Thursday, March 02, 2017 03:45:02 PM Patrick Bellasi wrote:
> > Currently, sg_cpu's flags are set to the value defined by the last call of
> > the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes
> > this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set.
> > 
> > When multiple CPU shares the same frequency domain it might happen that a
> > CPU which executed an RT task, right before entering IDLE, has one of the
> > SCHED_CPUFREQ_RT_DL flags set, permanently, until it exits IDLE.
> 
> But if it is idle, it won't be taken into account by sugov_next_freq_shared(), will it?

Yes, but:

1) This kind of "useless RT requests" are ignored only if more then
   TICK_NSEC have elapsed since the last update.

2) The proposed patch, apart from resetting the flags, it also bails
   out without potentially triggering an already too late switch to MAX,
   which starts also a new throttling interval.

3) By resetting the flags we keep the internal state machine more
   consistent with what the scheduler knows, i.e. we are now idle.

Considering overall these three points, IMO this small patch makes the
schedutil machinery a bit more predictable.
 
> Thanks,
> Rafael

Cheers Patrick

-- 
#include <best/regards.h>

Patrick Bellasi

  reply	other threads:[~2017-04-07 14:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 15:45 [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Patrick Bellasi
2017-03-02 15:45 ` [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter Patrick Bellasi
2017-03-03  3:41   ` Viresh Kumar
2017-03-06 14:29     ` Steven Rostedt
2017-03-15 18:06       ` Patrick Bellasi
2017-03-28 22:18   ` Rafael J. Wysocki
2017-04-07 14:59     ` Patrick Bellasi [this message]
2017-06-06  9:26   ` Viresh Kumar
2017-06-06 15:56     ` Rafael J. Wysocki
2017-06-06 18:03       ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections Patrick Bellasi
2017-03-03  5:19   ` Viresh Kumar
2017-03-03 12:12     ` Patrick Bellasi
2017-03-06  5:08       ` Viresh Kumar
2017-03-06 14:35   ` Steven Rostedt
2017-03-15 18:02     ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks Patrick Bellasi
2017-03-03  8:31   ` Viresh Kumar
2017-03-03 12:38     ` Patrick Bellasi
2017-03-15 11:52       ` Rafael J. Wysocki
2017-03-15 14:40         ` Patrick Bellasi
2017-03-15 23:32           ` Rafael J. Wysocki
2017-03-17 11:36             ` Patrick Bellasi
2017-04-07 15:30   ` Peter Zijlstra
2017-04-07 16:59     ` Patrick Bellasi
2017-03-02 15:45 ` [PATCH 4/6] cpufreq: schedutil: relax rate-limiting " Patrick Bellasi
2017-03-02 15:45 ` [PATCH 5/6] cpufreq: schedutil: avoid utilisation update when not necessary Patrick Bellasi
2017-03-02 15:45 ` [PATCH 6/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled Patrick Bellasi
2017-03-02 16:09 ` [PATCH 0/6] cpufreq: schedutil: fixes for flags updates Vincent Guittot
2017-03-02 17:11   ` Patrick Bellasi

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=20170407145909.GD29455@e110439-lin \
    --to=patrick.bellasi@arm.com \
    --cc=andresoportus@google.com \
    --cc=chris.redpath@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.com \
    --cc=john.stultz@linaro.org \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=timmurray@google.com \
    --cc=tkjos@android.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.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;
as well as URLs for NNTP newsgroup(s).