From: Mike Galbraith <efault@gmx.de>
To: Rohit Jain <rohit.k.jain@oracle.com>,
Steven Sistare <steven.sistare@oracle.com>,
linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, mingo@redhat.com, joelaf@google.com,
jbacik@fb.com, riel@redhat.com, juri.lelli@redhat.com,
dhaval.giani@oracle.com
Subject: Re: [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance
Date: Fri, 16 Feb 2018 05:53:30 +0100 [thread overview]
Message-ID: <1518756810.17014.32.camel@gmx.de> (raw)
In-Reply-To: <7e6ee88e-8462-b1ab-a7bf-536a2c576c7d@oracle.com>
On Thu, 2018-02-15 at 10:07 -0800, Rohit Jain wrote:
>
> > Rohit is running more tests with a patch that deletes
> > sysctl_sched_migration_cost from idle_balance, and for his patch but
> > with the 5000 usec mistake corrected back to 500 usec. So far both
> > give improvements over the baseline, but for different cases, so we
> > need to try more workloads before we draw any conclusions.
> >
> > Rohit, can you share your data so far?
>
> Results:
>
> In the following results, "Domain based" approach is as mentioned in the
> RFC sent out with the values fixed (As pointed out by Mike). "No check" is
> the patch where I just remove the check against sysctl_sched_migration_cost
>
> 1) Hackbench results on 2 socket, 44 core and 88 threads Intel x86 machine
> (lower is better):
>
> +--------------+-----------------+--------------------------+-------------------------+
> | | Without Patch |Domain Based |No Check |
> +------+-------+--------+--------+-----------------+--------+----------------+--------+
> |Loops | Groups|Average |%Std Dev|Average |%Std Dev|Average |%Std Dev|
> +------+-------+--------+--------+-----------------+--------+----------------+--------+
> |100000| 4 |9.701 |0.78 |7.971 (+17.84%) | 1.34 |8.919 (+8.07%) |1.07 |
> |100000| 8 |17.186 |0.77 |16.712 (+2.76%) | 0.87 |17.043 (+0.83%) |0.83 |
> |100000| 16 |30.378 |0.55 |29.780 (+1.97%) | 0.38 |29.565 (+2.67%) |0.29 |
> |100000| 32 |54.712 |0.54 |53.001 (+3.13%) | 0.19 |52.158 (+4.67%) |0.22 |
> +------+-------+--------+--------+-----------------+--------+----------------+--------+
previous numbers.
+-------+----+-------+-------------------+--------------------------+
| | | | Without patch |With patch |
+-------+----+-------+---------+---------+----------------+---------+
|Loops |FD |Groups | Average |%Std Dev |Average |%Std Dev |
+-------+----+-------+---------+---------+----------------+---------+
|100000 |40 |4 | 9.701 |0.78 |9.623 (+0.81%) |3.67 |
|100000 |40 |8 | 17.186 |0.77 |17.068 (+0.68%) |1.89 |
|100000 |40 |16 | 30.378 |0.55 |30.072 (+1.52%) |0.46 |
|100000 |40 |32 | 54.712 |0.54 |53.588 (+2.28%) |0.21 |
+-------+----+-------+---------+---------+----------------+---------+
My take on this (not that you have to sell it to me, you don't) when I
squint at these together is submit the one-liner, and take the rest
back to the drawing board. You've got nothing but high std dev numbers
in (imo) way too finicky/unrealistic hackbench to sell these not so
pretty patches.
I bet you can easily sell that one-liner, because that removes an old
wart (me stealing migration_cost in the first place), instead of making
wart a whole lot harder to intentionally not notice.
-Mike
next prev parent reply other threads:[~2018-02-16 4:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 22:19 [RFC 0/2] sched: Make idle_balance smarter about topology Rohit Jain
2018-02-08 22:19 ` [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance Rohit Jain
2018-02-09 3:42 ` Mike Galbraith
2018-02-09 16:08 ` Steven Sistare
2018-02-10 6:37 ` Mike Galbraith
2018-02-15 16:35 ` Steven Sistare
2018-02-15 18:07 ` Mike Galbraith
2018-02-15 18:21 ` Steven Sistare
2018-02-15 18:39 ` Mike Galbraith
2018-02-15 18:07 ` Rohit Jain
2018-02-16 4:53 ` Mike Galbraith [this message]
2018-02-08 22:19 ` [RFC 2/2] Introduce sysctl(s) for the migration costs Rohit Jain
2018-02-09 3:54 ` Mike Galbraith
2018-02-09 16:10 ` Steven Sistare
2018-02-09 17:08 ` Mike Galbraith
2018-02-09 17:33 ` Steven Sistare
2018-02-09 17:50 ` Mike Galbraith
2018-02-12 15:28 ` Peter Zijlstra
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=1518756810.17014.32.camel@gmx.de \
--to=efault@gmx.de \
--cc=dhaval.giani@oracle.com \
--cc=jbacik@fb.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rohit.k.jain@oracle.com \
--cc=steven.sistare@oracle.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