From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: xen-devel@lists.xensource.com
Subject: Re: Linux v3.12 + pv ticketlocks
Date: Wed, 11 Sep 2013 15:24:07 -0400 [thread overview]
Message-ID: <20130911192407.GA30412@phenom.dumpdata.com> (raw)
In-Reply-To: <208782456.20130911210505@eikelenboom.it>
On Wed, Sep 11, 2013 at 09:05:05PM +0200, Sander Eikelenboom wrote:
>
> Wednesday, September 11, 2013, 8:41:29 PM, you wrote:
>
> > On Wed, Sep 11, 2013 at 08:25:01PM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >>
> >> Just to confirm:
> >>
> >> - PV ticketlocks is on by default and doesn't neet a config option, to disable it at boot time it's possible to use "xen_nopvspin" as a kernel commandline parameter
>
> > Yes.
> >> - CONFIG_PARAVIRT_SPINLOCKS should be off, since that would enable the old bytelock pv-spinlock implementation which could now probably be removed ?
>
> > You still need CONFIG_PARAVIRT_SPINLOCKS=y to take advantage of it.
>
> > The bytelock pvspinlock is gone. If you compile without CONFIG_PARAVIRT_SPINLOCKS
> > then you will only use ticketlocks for all types of guests and baremtal. No
> > 'PV' variant.
>
> > The CONFIG_PARAVIRT_SPINLOCKS=y enables the PV ticketlock for all guests.
>
> Ok so the KConfig (help) entry for CONFIG_PARAVIRT_SPINLOCKS should perhaps also be updated ?
Yes!
>
> Since it for example still contains the "Unfortunately the downside is an up to 5%
> performance hit on native kernels, with various workloads." which afaik was one the things the PV ticketlock migitated,
> so it would be more feasible for distributions to have this option on for all general distro kernels ?
Yikes. That is true - needs to be updated as the results were the opposite:
Results:
=======
setup: 32 core machine with 32 vcpu KVM guest (HT off) with 8GB RAM
base = 3.11-rc
patched = base + pvspinlock V12
+-----------------+----------------+--------+
dbench (Throughput in MB/sec. Higher is better)
+-----------------+----------------+--------+
| base (stdev %)|patched(stdev%) | %gain |
+-----------------+----------------+--------+
| 15035.3 (0.3) |15150.0 (0.6) | 0.8 |
| 1470.0 (2.2) | 1713.7 (1.9) | 16.6 |
| 848.6 (4.3) | 967.8 (4.3) | 14.0 |
| 652.9 (3.5) | 685.3 (3.7) | 5.0 |
+-----------------+----------------+--------+
(I don't have the baremetal one - but it was pretty much 0%).
Please if you get a chance - please do send a patch to x86 folks
altering this.
Thanks!
prev parent reply other threads:[~2013-09-11 19:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 20:11 Linux v3.12 + pv ticketlocks Konrad Rzeszutek Wilk
2013-09-09 10:39 ` Ian Campbell
2013-09-09 14:03 ` Konrad Rzeszutek Wilk
2013-09-10 17:41 ` Dario Faggioli
2013-09-11 19:03 ` Konrad Rzeszutek Wilk
2013-09-13 15:17 ` Dario Faggioli
2013-09-13 4:44 ` Jeremy Fitzhardinge
2013-09-11 18:25 ` Sander Eikelenboom
2013-09-11 18:41 ` Konrad Rzeszutek Wilk
2013-09-11 19:05 ` Sander Eikelenboom
2013-09-11 19:24 ` Konrad Rzeszutek Wilk [this message]
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=20130911192407.GA30412@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=linux@eikelenboom.it \
--cc=xen-devel@lists.xensource.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).