From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Julia Lawall <julia.lawall@inria.fr>,
Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@redhat.com>,
kernel-janitors@vger.kernel.org,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel@vger.kernel.org,
Valentin Schneider <valentin.schneider@arm.com>,
Gilles Muller <Gilles.Muller@inria.fr>,
srinivas.pandruvada@linux.intel.com
Subject: default cpufreq gov, was: [PATCH] sched/fair: check for idle core
Date: Thu, 22 Oct 2020 14:02:13 +0200 [thread overview]
Message-ID: <20201022120213.GG2611@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <34115486.YmRjPRKJaA@kreacher>
On Thu, Oct 22, 2020 at 01:45:25PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 22, 2020 12:47:03 PM CEST Viresh Kumar wrote:
> > On 22-10-20, 09:11, Peter Zijlstra wrote:
> > > Well, but we need to do something to force people onto schedutil,
> > > otherwise we'll get more crap like this thread.
> > >
> > > Can we take the choice away? Only let Kconfig select which governors are
> > > available and then set the default ourselves? I mean, the end goal being
> > > to not have selectable governors at all, this seems like a good step
> > > anyway.
> >
> > Just to clarify and complete the point a bit here, the users can still
> > pass the default governor from cmdline using
> > cpufreq.default_governor=, which will take precedence over the one the
> > below code is playing with. And later once the kernel is up, they can
> > still choose a different governor from userspace.
>
> Right.
>
> Also some people simply set "performance" as the default governor and then
> don't touch cpufreq otherwise (the idea is to get everything to the max
> freq right away and stay in that mode forever). This still needs to be
> possible IMO.
Performance/powersave make sense to keep.
However I do want to retire ondemand, conservative and also very much
intel_pstate/active mode. I also have very little sympathy for
userspace.
We should start by making it hard to use them and eventually just delete
them outright.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Julia Lawall <julia.lawall@inria.fr>,
Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@redhat.com>,
kernel-janitors@vger.kernel.org,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel@vger.kernel.org,
Valentin Schneider <valentin.schneider@arm.com>,
Gilles Muller <Gilles.Muller@inria.fr>,
srinivas.pandruvada@linux.intel.com
Subject: default cpufreq gov, was: [PATCH] sched/fair: check for idle core
Date: Thu, 22 Oct 2020 12:02:13 +0000 [thread overview]
Message-ID: <20201022120213.GG2611@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <34115486.YmRjPRKJaA@kreacher>
On Thu, Oct 22, 2020 at 01:45:25PM +0200, Rafael J. Wysocki wrote:
> On Thursday, October 22, 2020 12:47:03 PM CEST Viresh Kumar wrote:
> > On 22-10-20, 09:11, Peter Zijlstra wrote:
> > > Well, but we need to do something to force people onto schedutil,
> > > otherwise we'll get more crap like this thread.
> > >
> > > Can we take the choice away? Only let Kconfig select which governors are
> > > available and then set the default ourselves? I mean, the end goal being
> > > to not have selectable governors at all, this seems like a good step
> > > anyway.
> >
> > Just to clarify and complete the point a bit here, the users can still
> > pass the default governor from cmdline using
> > cpufreq.default_governor=, which will take precedence over the one the
> > below code is playing with. And later once the kernel is up, they can
> > still choose a different governor from userspace.
>
> Right.
>
> Also some people simply set "performance" as the default governor and then
> don't touch cpufreq otherwise (the idea is to get everything to the max
> freq right away and stay in that mode forever). This still needs to be
> possible IMO.
Performance/powersave make sense to keep.
However I do want to retire ondemand, conservative and also very much
intel_pstate/active mode. I also have very little sympathy for
userspace.
We should start by making it hard to use them and eventually just delete
them outright.
next prev parent reply other threads:[~2020-10-22 12:02 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 16:37 [PATCH] sched/fair: check for idle core Julia Lawall
2020-10-20 16:37 ` Julia Lawall
2020-10-21 7:29 ` Vincent Guittot
2020-10-21 7:29 ` Vincent Guittot
2020-10-21 11:13 ` Peter Zijlstra
2020-10-21 11:13 ` Peter Zijlstra
2020-10-21 12:27 ` Vincent Guittot
2020-10-21 12:27 ` Vincent Guittot
2020-10-21 11:20 ` Mel Gorman
2020-10-21 11:20 ` Mel Gorman
2020-10-21 11:56 ` Julia Lawall
2020-10-21 11:56 ` Julia Lawall
2020-10-21 12:19 ` Peter Zijlstra
2020-10-21 12:19 ` Peter Zijlstra
2020-10-21 12:42 ` Julia Lawall
2020-10-21 12:42 ` Julia Lawall
2020-10-21 12:52 ` Peter Zijlstra
2020-10-21 12:52 ` Peter Zijlstra
2020-10-21 13:43 ` Julia Lawall
2020-10-21 18:18 ` Rafael J. Wysocki
2020-10-21 18:18 ` Rafael J. Wysocki
2020-10-21 18:15 ` Rafael J. Wysocki
2020-10-21 18:15 ` Rafael J. Wysocki
2020-10-21 19:47 ` Julia Lawall
2020-10-21 19:47 ` Julia Lawall
2020-10-21 20:25 ` Rafael J. Wysocki
2020-10-21 20:25 ` Rafael J. Wysocki
2020-10-21 13:10 ` Peter Zijlstra
2020-10-21 13:10 ` Peter Zijlstra
2020-10-21 18:11 ` Rafael J. Wysocki
2020-10-21 18:11 ` Rafael J. Wysocki
2020-10-22 4:41 ` Viresh Kumar
2020-10-22 4:53 ` Viresh Kumar
2020-10-22 7:11 ` Peter Zijlstra
2020-10-22 7:11 ` Peter Zijlstra
2020-10-22 10:47 ` Viresh Kumar
2020-10-22 10:59 ` Viresh Kumar
2020-10-22 11:45 ` Rafael J. Wysocki
2020-10-22 11:45 ` Rafael J. Wysocki
2020-10-22 12:02 ` Peter Zijlstra [this message]
2020-10-22 12:02 ` default cpufreq gov, was: " Peter Zijlstra
2020-10-22 12:19 ` Rafael J. Wysocki
2020-10-22 12:19 ` Rafael J. Wysocki
2020-10-22 12:29 ` Peter Zijlstra
2020-10-22 12:29 ` Peter Zijlstra
2020-10-22 14:52 ` Mel Gorman
2020-10-22 14:52 ` Mel Gorman
2020-10-22 14:58 ` Colin Ian King
2020-10-22 14:58 ` Colin Ian King
2020-10-22 15:12 ` Phil Auld
2020-10-22 15:12 ` Phil Auld
2020-10-22 16:35 ` Mel Gorman
2020-10-22 16:35 ` Mel Gorman
2020-10-22 17:59 ` Rafael J. Wysocki
2020-10-22 17:59 ` Rafael J. Wysocki
2020-10-22 20:32 ` Mel Gorman
2020-10-22 20:32 ` Mel Gorman
2020-10-22 20:39 ` Phil Auld
2020-10-22 20:39 ` Phil Auld
2020-10-22 15:25 ` Peter Zijlstra
2020-10-22 15:25 ` Peter Zijlstra
2020-10-22 15:55 ` Rafael J. Wysocki
2020-10-22 15:55 ` Rafael J. Wysocki
2020-10-22 16:29 ` Mel Gorman
2020-10-22 16:29 ` Mel Gorman
2020-10-22 20:10 ` Giovanni Gherdovich
2020-10-22 20:10 ` Giovanni Gherdovich
2020-10-22 20:16 ` Giovanni Gherdovich
2020-10-22 20:16 ` Giovanni Gherdovich
2020-10-23 7:03 ` Peter Zijlstra
2020-10-23 7:03 ` Peter Zijlstra
2020-10-23 17:46 ` Tom Lendacky
2020-10-23 17:46 ` Tom Lendacky
2020-10-26 19:52 ` Fontenot, Nathan
2020-10-26 19:52 ` Fontenot, Nathan
2020-10-22 15:45 ` A L
2020-10-22 15:45 ` A L
2020-10-22 15:55 ` Vincent Guittot
2020-10-22 15:55 ` Vincent Guittot
2020-10-23 5:11 ` Viresh Kumar
2020-10-23 5:23 ` Viresh Kumar
2020-10-22 16:23 ` [PATCH] cpufreq: Avoid configuring old governors as default with intel_pstate Rafael J. Wysocki
2020-10-22 16:23 ` Rafael J. Wysocki
2020-10-23 6:17 ` Viresh Kumar
2020-10-23 6:29 ` Viresh Kumar
2020-10-23 11:59 ` Rafael J. Wysocki
2020-10-23 11:59 ` Rafael J. Wysocki
2020-10-23 15:15 ` [PATCH v2] " Rafael J. Wysocki
2020-10-23 15:15 ` Rafael J. Wysocki
2020-10-27 3:01 ` Viresh Kumar
2020-10-27 3:13 ` Viresh Kumar
2020-10-27 11:11 ` default cpufreq gov, was: [PATCH] sched/fair: check for idle core Qais Yousef
2020-10-27 11:26 ` Valentin Schneider
2020-10-27 11:42 ` Qais Yousef
2020-10-27 11:48 ` Viresh Kumar
2020-10-27 11:48 ` Viresh Kumar
2020-10-23 6:12 ` Viresh Kumar
2020-10-23 6:24 ` Viresh Kumar
2020-10-23 15:06 ` Rafael J. Wysocki
2020-10-23 15:06 ` Rafael J. Wysocki
2020-10-27 3:01 ` Viresh Kumar
2020-10-27 3:13 ` Viresh Kumar
2020-10-22 11:21 ` AW: " Walter Harms
2020-10-22 11:21 ` Walter Harms
2020-10-21 12:28 ` Mel Gorman
2020-10-21 12:28 ` Mel Gorman
2020-10-21 12:25 ` Vincent Guittot
2020-10-21 12:25 ` Vincent Guittot
2020-10-21 12:47 ` Mel Gorman
2020-10-21 12:47 ` Mel Gorman
2020-10-21 12:56 ` Julia Lawall
2020-10-21 12:56 ` Julia Lawall
2020-10-21 13:18 ` Mel Gorman
2020-10-21 13:18 ` Mel Gorman
2020-10-21 13:24 ` Julia Lawall
2020-10-21 13:24 ` Julia Lawall
2020-10-21 15:08 ` Mel Gorman
2020-10-21 15:08 ` Mel Gorman
2020-10-21 15:18 ` Julia Lawall
2020-10-21 15:18 ` Julia Lawall
2020-10-21 15:23 ` Vincent Guittot
2020-10-21 15:23 ` Vincent Guittot
2020-10-21 15:33 ` Julia Lawall
2020-10-21 15:33 ` Julia Lawall
2020-10-21 15:19 ` Vincent Guittot
2020-10-21 15:19 ` Vincent Guittot
2020-10-21 17:00 ` Mel Gorman
2020-10-21 17:00 ` Mel Gorman
2020-10-21 17:39 ` Julia Lawall
2020-10-21 17:39 ` Julia Lawall
2020-10-21 13:48 ` Julia Lawall
2020-10-21 13:48 ` Julia Lawall
2020-10-21 15:26 ` Mel Gorman
2020-10-21 15:26 ` Mel Gorman
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=20201022120213.GG2611@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Gilles.Muller@inria.fr \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=julia.lawall@inria.fr \
--cc=juri.lelli@redhat.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=valentin.schneider@arm.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 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.