From: Peter Zijlstra <peterz@infradead.org>
To: Doug Smythies <dsmythies@telus.net>
Cc: "'Rafael J. Wysocki'" <rafael@kernel.org>,
'Giovanni Gherdovich' <ggherdovich@suse.com>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
'Linux PM' <linux-pm@vger.kernel.org>,
'LKML' <linux-kernel@vger.kernel.org>,
'Viresh Kumar' <viresh.kumar@linaro.org>,
'Srinivas Pandruvada' <srinivas.pandruvada@linux.intel.com>,
efault@gmx.de, Mel Gorman <mgorman@suse.de>,
Vincent Guittot <vincent.guittot@linaro.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Juri Lelli <juri.lelli@gmail.com>
Subject: Re: [PATCH v1 0/4] cpufreq: Allow drivers to receive more information from the governor
Date: Fri, 18 Dec 2020 16:32:31 +0100 [thread overview]
Message-ID: <20201218153231.GB2414@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <001d01d6cd96$601c8a80$20559f80$@net>
On Tue, Dec 08, 2020 at 11:14:36AM -0800, Doug Smythies wrote:
> At least on my system, it is most evident for some of the pipe type tests,
> where the schedutil governor has never really known what to do. This patch
> set seems to add enough of a downward bias that this version of the schedutil
> governor now behaves much like the other versions
Yeah, pipe relies on task-task interaction, where one task waits on
another, and by boosting the producer the consumer can start earlier and
we get more cycles done etc.. Rather similar to IO-wait, where by
boosting the producer we gain throughput.
schedutil doesn't track anything useful here, but it is a semi common
pattern and it would be really good if we could somehow fix this.
We obviously have access to the task A wakes task B information, but I'm
not sure what to do with it, we're tried some things like this in the
past (although for slightly different reasons) and they've always ended
up being a mess :/
next prev parent reply other threads:[~2020-12-18 15:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 16:25 Rafael J. Wysocki
2020-12-07 16:28 ` [PATCH v1 1/4] cpufreq: schedutil: Add util to struct sg_cpu Rafael J. Wysocki
2020-12-08 8:33 ` Viresh Kumar
2020-12-09 17:17 ` Rafael J. Wysocki
2020-12-07 16:29 ` [PATCH v1 2/4] cpufreq: schedutil: Adjust utilization instead of frequency Rafael J. Wysocki
2020-12-08 8:51 ` Viresh Kumar
2020-12-08 17:01 ` Rafael J. Wysocki
2020-12-09 5:16 ` Viresh Kumar
2020-12-09 15:32 ` Rafael J. Wysocki
2020-12-14 11:07 ` Viresh Kumar
2020-12-07 16:35 ` [PATCH v1 3/4] cpufreq: Add special-purpose fast-switching callback for drivers Rafael J. Wysocki
2020-12-08 9:02 ` Viresh Kumar
2020-12-15 4:16 ` Viresh Kumar
2020-12-15 15:38 ` Rafael J. Wysocki
2020-12-07 16:38 ` [PATCH v1 4/4] cpufreq: intel_pstate: Implement the ->adjust_perf() callback Rafael J. Wysocki
2020-12-08 12:43 ` Peter Zijlstra
2020-12-08 17:10 ` Rafael J. Wysocki
2020-12-08 16:30 ` [PATCH v1 0/4] cpufreq: Allow drivers to receive more information from the governor Giovanni Gherdovich
2020-12-08 17:13 ` Rafael J. Wysocki
2020-12-08 19:14 ` Doug Smythies
2020-12-13 19:12 ` Doug Smythies
2020-12-18 15:32 ` Peter Zijlstra [this message]
2020-12-14 20:01 ` [PATCH v2 0/3] " Rafael J. Wysocki
2020-12-14 20:04 ` [PATCH v2 1/3] cpufreq: schedutil: Add util to struct sg_cpu Rafael J. Wysocki
2020-12-14 20:08 ` [PATCH v2 2/3] cpufreq: Add special-purpose fast-switching callback for drivers Rafael J. Wysocki
2020-12-14 20:09 ` [PATCH v2 3/3] cpufreq: intel_pstate: Implement the ->adjust_perf() callback Rafael J. Wysocki
2020-12-15 3:29 ` Srinivas Pandruvada
2020-12-15 4:16 ` [PATCH v2 0/3] cpufreq: Allow drivers to receive more information from the governor Viresh Kumar
2020-12-17 15:26 ` Doug Smythies
2020-12-21 10:41 ` Rafael J. Wysocki
2020-12-18 16:11 ` Giovanni Gherdovich
2020-12-21 16:11 ` Rafael J. Wysocki
2020-12-23 13:06 ` Giovanni Gherdovich
2020-12-28 19:11 ` Rafael J. Wysocki
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=20201218153231.GB2414@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dsmythies@telus.net \
--cc=efault@gmx.de \
--cc=ggherdovich@suse.com \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--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®