From: Peter Zijlstra <peterz@infradead.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Ingo Molnar <mingo@redhat.com>,
linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
dietmar.eggemann@arm.com, morten.rasmussen@arm.com,
juri.lelli@redhat.com, tkjos@android.com, joelaf@google.com,
linux-kernel@vger.kernel.org, patrick.bellasi@arm.com
Subject: Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags
Date: Wed, 20 Dec 2017 09:31:15 +0100 [thread overview]
Message-ID: <20171220083115.n4mc4pdkvycakce2@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20171220040446.GS19815@vireshk-i7>
On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
> On 19-12-17, 20:25, Peter Zijlstra wrote:
> > Yeah, not happy about this either; we had code that did the right thing
> > without this extra tracking I think.
>
> Sure, but how do you suggest we fix the problems we are facing with
> the current design? Patrick had a completely different proposal for
> solving those problems, which I didn't like very much. This patchset
> replaced these patches from Patrick:
Please use the normal link format:
https://lkml.kernel.org/r/$MSGID
Then I can find them without having to resort to a frigging browser
thing.
I'll try and dig through the email I have.
> > Also, we can look at the rq state if we want to, we don't need to
> > duplicate that state.
>
> Well that also looks fine to me, and that would mean this:
>
> - We remove SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL flags, but still
> call the utilization callbacks from RT and DL classes.
Didn't juri have patches to make DL do something sane? But yes, I think
those flags are part of the problem.
> - From the utilization handler, we check runqueues of all three sched
> classes to see if they have some work pending (this can be done
> smartly by checking only RT first and skipping other checks if RT
> has some work).
No that's wrong. DL should provide a minimum required based on existing
reservations, we can add the expected CFS average on top and request
that.
And for RT all we need to know is if current is of that class, otherwise
we don't care.
next prev parent reply other threads:[~2017-12-20 8:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 9:53 [PATCH 0/4] sched: cpufreq: Track util " Viresh Kumar
2017-12-13 9:53 ` [PATCH 1/4] cpufreq: schedutil: Initialize sg_cpu->flags to 0 Viresh Kumar
2017-12-13 11:13 ` Juri Lelli
2017-12-13 11:22 ` Viresh Kumar
2018-01-10 12:15 ` [tip:sched/core] sched/cpufreq: " tip-bot for Viresh Kumar
2017-12-13 9:53 ` [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags Viresh Kumar
2017-12-13 11:26 ` Juri Lelli
2017-12-13 11:29 ` Viresh Kumar
2017-12-16 16:40 ` Rafael J. Wysocki
2017-12-16 16:47 ` Viresh Kumar
2017-12-17 0:19 ` Rafael J. Wysocki
2017-12-18 4:59 ` Viresh Kumar
2017-12-18 11:35 ` Rafael J. Wysocki
2017-12-18 11:59 ` Viresh Kumar
2017-12-18 12:14 ` Patrick Bellasi
2017-12-19 3:12 ` Viresh Kumar
2017-12-19 3:18 ` Joel Fernandes
2017-12-19 3:22 ` Viresh Kumar
2017-12-19 3:26 ` Viresh Kumar
2017-12-19 3:30 ` Joel Fernandes
2017-12-19 3:41 ` Viresh Kumar
2017-12-19 10:44 ` Rafael J. Wysocki
2017-12-18 17:34 ` Rafael J. Wysocki
2017-12-19 19:25 ` Peter Zijlstra
2017-12-20 4:04 ` Viresh Kumar
2017-12-20 8:31 ` Peter Zijlstra [this message]
2017-12-20 8:48 ` Viresh Kumar
2017-12-20 9:17 ` Peter Zijlstra
2017-12-20 12:55 ` Patrick Bellasi
2017-12-20 13:28 ` Peter Zijlstra
2017-12-20 14:31 ` Patrick Bellasi
2017-12-20 14:52 ` Rafael J. Wysocki
2017-12-20 15:01 ` Patrick Bellasi
2017-12-20 14:47 ` Rafael J. Wysocki
2017-12-20 14:51 ` Peter Zijlstra
2017-12-20 17:27 ` Juri Lelli
2017-12-20 18:17 ` Peter Zijlstra
2017-12-13 9:53 ` [PATCH 3/4] cpufreq: schedutil: Don't pass flags to sugov_set_iowait_boost() Viresh Kumar
2017-12-13 11:28 ` Juri Lelli
2018-01-10 12:15 ` [tip:sched/core] sched/cpufreq: " tip-bot for Viresh Kumar
2017-12-13 9:53 ` [PATCH 4/4] cpufreq: schedutil: Don't call sugov_get_util() unnecessarily Viresh Kumar
2017-12-13 11:34 ` Juri Lelli
2017-12-13 12:02 ` Viresh Kumar
2017-12-19 3:26 ` Joel Fernandes
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=20171220083115.n4mc4pdkvycakce2@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=rjw@rjwysocki.net \
--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
all inboxes | Powered by JetHome®