public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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