From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>,
Matt Fleming <matt@codeblueprint.co.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS
Date: Fri, 02 Feb 2018 12:01:37 -0800 [thread overview]
Message-ID: <1517601697.83171.361.camel@linux.intel.com> (raw)
In-Reply-To: <20180202194801.mhvuwzbz6pauf63f@techsingularity.net>
On Fri, 2018-02-02 at 19:48 +0000, Mel Gorman wrote:
> On Fri, Feb 02, 2018 at 06:54:24AM -0800, Srinivas Pandruvada wrote:
> > > > > No idea, desired would be the one I would start with, it
> > > > > matches
> > > > > with
> > > > > the intent here. But I've no idea what our current HWP
> > > > > implementation
> > > > > actually does with it.
> > > >
> > > > Desired !=0 will disable HWP autonomous mode of frequency
> > > > selection.
> > >
> > > But I don't think it will just run at "desired" then, will it?
> >
> > HWP all are these hints only not a guarantee.
>
> Sure, but the lack on detection when tasks are low utilisation but
> still
> latency/throughput sensitive is problematic. Users shouldn't have to
> know they need to disable HWP or set performance goernor out of the
> box.
> It's only going to get worse as sockets get larger.
I am not saying that we shouldn't do anything. Can you give me some
workloads which you care the most?
>
> > There are totally different way HWP is handled in client an
> > servers.
> > If you set desired all heuristics they collected will be dumped, so
> > they suggest don't set desired when you are in autonomous mode. If
> > we
> > really want a boost set the EPP. We know that EPP makes lots of
> > measurable difference.
> >
>
> Sure boosting EPP makes a difference -- it's essentially what the
> performance
> goveror does and I know that can be done by a user but it's still
> basically a
> cop-out. Default performance for low utilisation or lightly loaded
> machines
> is poor. Maybe it should be set based on the ACPI preferred profile
> but
> that information is not always available. It would be nice if *some*
> sort of hint about new migrations or tasks waking from IO would be
> desirable.
EPP is a range not a single value. So you don't need to make EPP=0 as a
performance governor. PeterZ gave me some scheduler change to
experiment, which can be used as hint to play with EPP.
Thanks,
Srinivas
next prev parent reply other threads:[~2018-02-02 20:01 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
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 [this message]
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=1517601697.83171.361.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mgorman@techsingularity.net \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).