From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Linux PM <linux-pm@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@android.com>,
Joel Fernandes <joelaf@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags
Date: Mon, 18 Dec 2017 10:29:45 +0530 [thread overview]
Message-ID: <20171218045945.GG19815@vireshk-i7> (raw)
In-Reply-To: <20456740.6R3DDKEUDv@aspire.rjw.lan>
On 17-12-17, 01:19, Rafael J. Wysocki wrote:
> We can do that in principle, but why should it return early? Maybe it's
> a good time to update things, incidentally?
>
> I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very
> much specific to schedutil and blatantly ignores everybody else.
>
> Alternatively, you could add two flags for clearing SCHED_CPUFREQ_RT and
> SCHED_CPUFREQ_DL that could just be ingored entirely by intel_pstate.
>
> So, why don't you make SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL "sticky" until,
> say, SCHED_CPUFREQ_NO_RT and SCHED_CPUFREQ_NO_DL are passed, respectively?
I didn't like adding scheduling class specific flags, and wanted the code to
treat all of them in the same way. And then the governors can make a policy over
that, on what to ignore and what not to. For example with the current patchset,
the governors can know when nothing else is queued on a CPU and CPU is going to
get into idle loop. They can choose to (or not to) do something in that case.
I just thought that writing consistent (i.e. no special code) code across all
classes would be better.
--
viresh
next prev parent reply other threads:[~2017-12-18 4:59 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 update flags 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 [this message]
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
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=20171218045945.GG19815@vireshk-i7 \
--to=viresh.kumar@linaro.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=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tkjos@android.com \
--cc=vincent.guittot@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 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.