From: Rik van Riel <riel@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Rafael Aquini <aquini@redhat.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: Fri, 11 Jan 2013 15:11:29 -0500 [thread overview]
Message-ID: <50F071F1.6090600@redhat.com> (raw)
In-Reply-To: <20130110173603.GA31549@linux.vnet.ibm.com>
On 01/10/2013 12:36 PM, Raghavendra K T wrote:
> * 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]
I believe I understand why this is happening.
Modern Intel and AMD CPUs have a feature called Pause Loop Exiting (PLE)
and Pause Filter (PF), respectively. This feature is used to trap to
the host when the guest is spinning on a spinlock.
This allows the host to run something else, and having the spinner
temporarily yield the CPU. Effectively, this causes the KVM code
to already do some limited amount of spinlock backoff code, in the
host.
Adding more backoff code in the guest can lead to wild delays in
acquiring locks, and generally bad performance.
I suspect that when running in a virtual machine, we should limit
the delay factor to something much smaller, since the host will take
care of most of the backoff for us.
Maybe a maximum delay value of ~10 would do the trick for KVM
guests.
We should be able to get this right by placing the value for the
maximum delay in a __read_mostly section and setting it to something
small from an init function when we detect we are running in a
virtual machine.
Let me cook up, and test, a patch that does that...
--
All rights reversed
next prev parent reply other threads:[~2013-01-11 20:11 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
2013-01-11 20:11 ` Rik van Riel [this message]
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=50F071F1.6090600@redhat.com \
--to=riel@redhat.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=raghavendra.kt@linux.vnet.ibm.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).