linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).