From: Matt Fleming <matt@codeblueprint.co.uk>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Morten.Rasmussen@arm.com, dietmar.eggemann@arm.com,
kernellwp@gmail.com, yuyang.du@intel.com,
umgwanakikbuti@gmail.com,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group
Date: Thu, 8 Dec 2016 14:09:33 +0000 [thread overview]
Message-ID: <20161208140933.GF5462@codeblueprint.co.uk> (raw)
In-Reply-To: <20161205133546.GN20785@codeblueprint.co.uk>
On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote:
> On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote:
> >
> > Hi Matt,
> >
> > Thanks for the results.
> >
> > During the review, it has been pointed out by Morten that the test condition
> > (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than
> > (100*min_avg_load > imbalance_scale*this_avg_load). But i see lower
> > performances with this change. Coud you run tests with the change below on
> > top of the patchset ?
> >
> > ---
> > kernel/sched/fair.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index e8d1ae7..0129fbb 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -5514,7 +5514,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> > if (!idlest ||
> > (min_runnable_load > (this_runnable_load + imbalance)) ||
> > ((this_runnable_load < (min_runnable_load + imbalance)) &&
> > - (100*min_avg_load > imbalance_scale*this_avg_load)))
> > + (100*this_avg_load < imbalance_scale*min_avg_load)))
> > return NULL;
> > return idlest;
> > }
>
> Queued for testing.
Most of the machines didn't notice the difference with this new patch.
However, I did come across one test that showed a negative change,
hackbench-thread-pipes
4.9.0-rc6 4.9.0-rc6 4.9.0-rc6 4.9.0-rc6
tip-sched fix-fig-for-fork fix-sig fix-fig-for-fork-v2
Amean 1 0.1266 ( 0.00%) 0.1269 ( -0.23%) 0.1287 ( -1.69%) 0.1357 ( -7.22%)
Amean 4 0.4989 ( 0.00%) 0.5174 ( -3.72%) 0.5251 ( -5.27%) 0.5117 ( -2.58%)
Amean 7 0.8510 ( 0.00%) 0.8517 ( -0.08%) 0.8964 ( -5.34%) 0.8801 ( -3.42%)
Amean 12 1.0699 ( 0.00%) 1.0484 ( 2.00%) 1.0147 ( 5.15%) 1.0759 ( -0.56%)
Amean 21 1.2816 ( 0.00%) 1.2140 ( 5.27%) 1.1879 ( 7.31%) 1.2414 ( 3.13%)
Amean 30 1.4440 ( 0.00%) 1.4003 ( 3.03%) 1.3969 ( 3.26%) 1.4057 ( 2.65%)
Amean 48 1.5773 ( 0.00%) 1.5983 ( -1.33%) 1.3984 ( 11.34%) 1.5624 ( 0.94%)
Amean 79 2.2343 ( 0.00%) 2.3066 ( -3.24%) 2.0053 ( 10.25%) 2.2630 ( -1.29%)
Amean 96 2.6736 ( 0.00%) 2.4313 ( 9.06%) 2.4181 ( 9.55%) 2.4717 ( 7.55%)
4.9.0-rc6 4.9.0-rc6 4.9.0-rc6 4.9.0-rc6
tip-schedfix-fig-for-fork fix-sigfix-fig-for-fork-v2
User 129.53 128.64 127.70 131.00
System 1784.54 1744.21 1654.08 1744.00
Elapsed 92.07 90.44 86.95 91.00
Looking at the 48 and 79 groups rows for mean there's a noticeable
drop off in performance of ~10%, which should be outside of the noise
for this test. This is a 2 socket, 4 NUMA node (yes, really), 24 cpus
AMD opteron circa 2010.
Given the age of this machine, I don't think it's worth holding up the
patch.
next prev parent reply other threads:[~2016-12-08 14:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 15:34 [PATCH 0/2 v2] sched: improve spread of tasks during fork Vincent Guittot
2016-11-25 15:34 ` [PATCH 1/2 v2] sched: fix find_idlest_group for fork Vincent Guittot
2016-11-28 17:01 ` Matt Fleming
2016-11-28 17:20 ` Vincent Guittot
2016-11-29 10:57 ` Morten Rasmussen
2016-11-29 11:42 ` Peter Zijlstra
2016-11-29 11:44 ` Matt Fleming
2016-11-29 12:30 ` Peter Zijlstra
2016-11-29 14:46 ` Morten Rasmussen
2016-12-05 8:48 ` Peter Zijlstra
2016-11-29 13:04 ` Vincent Guittot
2016-11-29 14:50 ` Morten Rasmussen
2016-11-29 14:57 ` Vincent Guittot
2016-12-03 23:25 ` Matt Fleming
2016-12-05 9:17 ` Vincent Guittot
2016-11-25 15:34 ` [PATCH 2/2 v2] sched: use load_avg for selecting idlest group Vincent Guittot
2016-11-30 12:49 ` Morten Rasmussen
2016-11-30 13:49 ` Vincent Guittot
2016-11-30 13:54 ` Vincent Guittot
2016-11-30 14:24 ` Morten Rasmussen
2016-12-02 15:20 ` Vincent Guittot
2016-12-02 22:24 ` Matt Fleming
2016-11-30 14:23 ` Morten Rasmussen
2016-12-03 3:31 ` Brendan Gregg
2016-12-03 21:47 ` Matt Fleming
2016-12-05 9:27 ` Vincent Guittot
2016-12-05 13:35 ` Matt Fleming
2016-12-08 14:09 ` Matt Fleming [this message]
2016-12-08 14:33 ` Vincent Guittot
2016-11-28 17:02 ` [PATCH 0/2 v2] sched: improve spread of tasks during fork Matt Fleming
2016-11-28 17:20 ` Vincent Guittot
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=20161208140933.GF5462@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=Morten.Rasmussen@arm.com \
--cc=brendan.d.gregg@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=kernellwp@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=umgwanakikbuti@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=yuyang.du@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome