From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Rafael Aquini <aquini@redhat.com>, Rik van Riel <riel@redhat.com>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, walken@google.com,
eric.dumazet@gmail.com, lwoodman@redhat.com, jeremy@goop.org,
Jan Beulich <JBeulich@novell.com>,
knoel@redhat.com, chegu_vinod@hp.com, mingo@redhat.com
Subject: Re: [PATCH 0/5] x86,smp: make ticket spinlock proportional backoff w/ auto tuning
Date: Thu, 10 Jan 2013 23:06:03 +0530 [thread overview]
Message-ID: <20130110173603.GA31549@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130110022722.GA1636@x61.redhat.com>
* Rafael Aquini <aquini@redhat.com> [2013-01-10 00:27:23]:
> On Wed, Jan 09, 2013 at 06:20:35PM +0530, Raghavendra K T wrote:
> > I ran kernbench on 32 core (mx3850) machine with 3.8-rc2 base.
> > x base_3.8rc2
> > + rik_backoff
> > N Min Max Median Avg Stddev
> > x 8 222.977 231.16 227.735 227.388 3.1512986
> > + 8 218.75 232.347 229.1035 228.25425 4.2730225
> > No difference proven at 95.0% confidence
>
> I got similar results on smaller systems (1 socket, dual-cores and quad-cores)
> when running Rik's latest series, no big difference for good nor for worse,
> but I also think Rik's work is meant to address bigger systems with more cores
> contending for any given spinlock.
I was able to do the test on same 32 core machine with
4 guests (8GB RAM, 32 vcpu).
Here are the results
base = 3.8-rc2
patched = base + Rik V3 backoff series [patch 1-4]
+-----------+-----------+-----------+------------+-----------+
kernbench (sec lower is better)
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improve
+-----------+-----------+-----------+------------+-----------+
44.3000 2.0404 46.7928 1.7518 -5.62709
94.8262 5.1444 102.4737 7.8406 -8.06475
156.0540 14.5797 167.6888 9.7110 -7.45562
202.3225 15.8906 213.1435 17.1778 -5.34839
+-----------+-----------+-----------+------------+-----------+
+-----------+-----------+-----------+------------+-----------+
sysbench (sec lower is better)
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improve
+-----------+-----------+-----------+------------+-----------+
16.8512 0.4164 17.7301 0.3761 -5.21565
13.0411 0.4115 12.9380 0.1554 0.79058
18.4573 0.2123 18.4662 0.2005 -0.04822
24.2021 0.1713 24.3690 0.3270 -0.68961
+-----------+-----------+-----------+------------+-----------+
+-----------+-----------+-----------+------------+-----------+
ebizzy (record/sec higher is better)
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improve
+-----------+-----------+-----------+------------+-----------+
2494.4000 27.5447 2400.6000 83.4255 -3.76042
2636.6000 302.9658 2757.5000 147.5137 4.58545
2236.8333 239.6531 2131.6667 156.1534 -4.70158
1768.8750 142.5437 1901.3750 295.2147 7.49064
+-----------+-----------+-----------+------------+-----------+
+-----------+-----------+-----------+------------+-----------+
dbench (throughput in MB/sec higher is better)
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improve
+-----------+-----------+-----------+------------+-----------+
10076.9180 2410.9655 5870.7460 4297.4532 xxxxxxx
2152.5220 88.2853 1517.8270 61.9742 -29.48611
1334.9608 34.3247 1078.4275 38.2288 -19.21654
946.6355 32.0426 753.0757 25.5302 -20.44713
+-----------+-----------+-----------+------------+-----------+
Please note that I have put dbench_1x result as xxxx since I observed
very high variance in the result.
next prev parent reply other threads:[~2013-01-10 17:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 22:26 [PATCH 0/5] x86,smp: make ticket spinlock proportional backoff w/ auto tuning Rik van Riel
2013-01-08 22:30 ` [PATCH 3/5] x86,smp: auto tune spinlock backoff delay factor Rik van Riel
2013-01-10 3:13 ` Rafael Aquini
2013-01-10 12:49 ` Michel Lespinasse
2013-01-08 22:31 ` [PATCH 4/5] x86,smp: keep spinlock delay values per hashed spinlock address Rik van Riel
2013-01-10 3:14 ` Rafael Aquini
2013-01-10 13:01 ` Michel Lespinasse
2013-01-10 13:05 ` Rik van Riel
2013-01-10 13:15 ` Michel Lespinasse
2013-01-08 22:32 ` [DEBUG PATCH 5/5] x86,smp: add debugging code to track spinlock delay value Rik van Riel
2013-01-08 22:32 ` [PATCH 2/5] x86,smp: proportional backoff for ticket spinlocks Rik van Riel
2013-01-08 22:50 ` Eric Dumazet
2013-01-08 22:54 ` Rik van Riel
2013-01-10 2:30 ` Rafael Aquini
2013-01-08 22:32 ` [PATCH 1/5] x86,smp: move waiting on contended ticket lock out of line Rik van Riel
2013-01-08 22:43 ` Eric Dumazet
2013-01-10 17:38 ` Raghavendra K T
2013-01-09 12:50 ` [PATCH 0/5] x86,smp: make ticket spinlock proportional backoff w/ auto tuning Raghavendra K T
2013-01-10 2:27 ` Rafael Aquini
2013-01-10 17:36 ` Raghavendra K T [this message]
2013-01-11 20:11 ` Rik van Riel
2013-01-13 18:07 ` Raghavendra K T
2013-01-10 15:19 ` Mike Galbraith
2013-01-10 15:31 ` Rik van Riel
2013-01-10 19:30 ` Mike Galbraith
2013-01-24 13:28 ` Ingo Molnar
2013-01-10 22:24 ` Chegu Vinod
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=20130110173603.GA31549@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=JBeulich@novell.com \
--cc=aquini@redhat.com \
--cc=chegu_vinod@hp.com \
--cc=eric.dumazet@gmail.com \
--cc=jeremy@goop.org \
--cc=knoel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=mingo@redhat.com \
--cc=riel@redhat.com \
--cc=walken@google.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;
as well as URLs for NNTP newsgroup(s).