From: Peter Zijlstra <peterz@infradead.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>,
Matt Fleming <matt@codeblueprint.co.uk>,
LKML <linux-kernel@vger.kernel.org>,
rjw@rjwysocki.net, srinivas.pandruvada@linux.intel.com
Subject: Re: [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS
Date: Tue, 30 Jan 2018 14:15:31 +0100 [thread overview]
Message-ID: <20180130131531.GD2269@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20180130125718.iwntjuvcp3yplvdx@techsingularity.net>
On Tue, Jan 30, 2018 at 12:57:18PM +0000, Mel Gorman wrote:
> On Tue, Jan 30, 2018 at 12:50:54PM +0100, Peter Zijlstra wrote:
> > Not saying this patch is bad; but Rafael / Srinivas we really should do
> > better. Why isn't cpufreq (esp. sugov) fixing this? HWP or not, we can
> > still give it hints, and it looks like we're not doing that.
> >
>
> I'm not sure if HWP can fix it because of the per-cpu nature of its
> decisions. I believe it can only give the most basic of hints to hardware
> like an energy performance profile or bias (EPP and EPB respectively).
> Of course HWP can be turned off but not many people can detect that it's
> an appropriate decision, or even desirable, and there is always the caveat
> that disabling it increases the system CPU footprint.
IA32_HWP_REQUEST has "Minimum_Performance", "Maximum_Performance" and
"Desired_Performance" fields which can be used to give explicit
frequency hints. And we really _should_ be doing that.
Because, esp. in this scenario; a task migrating; the hardware really
can't do anything sensible, whereas the OS _knows_.
next prev parent reply other threads:[~2018-01-30 13:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 10:45 [PATCH 0/4] Reduce migrations and unnecessary spreading of load to multiple CPUs Mel Gorman
2018-01-30 10:45 ` [PATCH 1/4] sched/fair: Remove unnecessary parameters from wake_affine_idle Mel Gorman
2018-02-06 11:55 ` [tip:sched/urgent] sched/fair: Remove unnecessary parameters from wake_affine_idle() tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 2/4] sched/fair: Restructure wake_affine to return a CPU id Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] sched/fair: Restructure wake_affine*() " tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 3/4] sched/fair: Do not migrate if the prev_cpu is idle Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] " tip-bot for Mel Gorman
2018-01-30 10:45 ` [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS Mel Gorman
2018-01-30 11:50 ` Peter Zijlstra
2018-01-30 12:57 ` Mel Gorman
2018-01-30 13:15 ` Peter Zijlstra [this message]
2018-01-30 13:25 ` Mel Gorman
2018-01-30 13:40 ` Peter Zijlstra
2018-01-30 14:06 ` Mel Gorman
2018-01-31 9:22 ` Rafael J. Wysocki
2018-01-31 10:17 ` Peter Zijlstra
2018-01-31 11:54 ` Mel Gorman
2018-01-31 17:44 ` Srinivas Pandruvada
2018-02-01 9:11 ` Peter Zijlstra
2018-02-01 7:50 ` Rafael J. Wysocki
2018-02-01 9:11 ` Peter Zijlstra
2018-02-01 13:18 ` Srinivas Pandruvada
2018-02-02 11:00 ` Rafael J. Wysocki
2018-02-02 14:54 ` Srinivas Pandruvada
2018-02-02 19:48 ` Mel Gorman
2018-02-02 20:01 ` Srinivas Pandruvada
2018-02-05 11:10 ` Mel Gorman
2018-02-05 17:04 ` Srinivas Pandruvada
2018-02-05 17:50 ` Mel Gorman
2018-02-04 8:42 ` Rafael J. Wysocki
2018-02-04 8:38 ` Rafael J. Wysocki
2018-02-02 11:42 ` Rafael J. Wysocki
2018-02-02 12:46 ` Peter Zijlstra
2018-02-02 12:55 ` Peter Zijlstra
2018-02-02 14:08 ` Peter Zijlstra
2018-02-03 16:30 ` Srinivas Pandruvada
2018-02-05 10:44 ` Peter Zijlstra
2018-02-05 10:58 ` Ingo Molnar
2018-02-02 12:58 ` Peter Zijlstra
2018-02-02 13:27 ` Mel Gorman
2018-01-30 13:15 ` Mike Galbraith
2018-01-30 13:25 ` Peter Zijlstra
2018-01-30 13:35 ` Mike Galbraith
2018-01-30 11:53 ` Peter Zijlstra
2018-01-30 12:59 ` Mel Gorman
2018-01-30 13:06 ` Peter Zijlstra
2018-01-30 13:18 ` Mel Gorman
2018-02-06 11:56 ` [tip:sched/urgent] " tip-bot for 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=20180130131531.GD2269@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mgorman@techsingularity.net \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
/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.