linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <waiman.long@hpe.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Waiman Long <Waiman.Long@hp.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression
Date: Wed, 09 Sep 2015 22:09:20 -0400	[thread overview]
Message-ID: <55F0E650.1030207@hpe.com> (raw)
In-Reply-To: <20150906234708.GP26895@dastard>

On 09/06/2015 07:47 PM, Dave Chinner wrote:
> On Fri, Sep 04, 2015 at 01:32:33PM +0200, Peter Zijlstra wrote:
>> On Fri, Sep 04, 2015 at 06:12:34PM +1000, Dave Chinner wrote:
>>> You probably don't even need a VM to reproduce it - that would
>>> certainly be an interesting counterpoint if it didn't....
>> Even though you managed to restore your DEBUG_SPINLOCK performance by
>> changing virt_queued_spin_lock() to use __delay(1), I ran the thing on
>> actual hardware just to test.
>>
>> [ Note: In any case, I would recommend you use (or at least try)
>>    PARAVIRT_SPINLOCKS if you use VMs, as that is where we were looking for
>>    performance, the test-and-set fallback really wasn't meant as a
>>    performance option (although it clearly sucks worse than expected).
> FSUse%        Count         Size    Files/sec     App Overhead
>       0      1600000            0     319431.5         10116018
>       0      3200000            0     307824.5         10054299
>       0      4800000            0     296971.5         10770197
>       0      6400000            0     281653.6         11748423
> ....
>
> PARAVIRT_SPINLOCKS seems to work OK these days, too. I'll leave that
> set so I'll end up testing whatever comes along down that pipe...
>
> Cheers,
>
> Dave.

I am working on patches to improve PV qspinlock performance and will run 
your fstest to verify that there will be no regression.

Cheers,
Longman

  reply	other threads:[~2015-09-10  2:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04  5:48 [4.2, Regression] Queued spinlocks cause major XFS performance regression Dave Chinner
2015-09-04  6:39 ` Linus Torvalds
2015-09-04  7:11   ` Dave Chinner
2015-09-04  7:31     ` Juergen Gross
2015-09-04  7:55     ` Peter Zijlstra
2015-09-04  8:29     ` Dave Chinner
2015-09-04 15:05       ` Linus Torvalds
2015-09-04 15:14         ` Peter Zijlstra
2015-09-04 15:21           ` Linus Torvalds
2015-09-04 15:30             ` Peter Zijlstra
2015-09-04 15:54               ` Peter Zijlstra
2015-09-10  2:06                 ` Waiman Long
2015-09-04 15:58               ` Linus Torvalds
2015-09-05 17:45                 ` Peter Zijlstra
2015-09-04 15:25           ` Peter Zijlstra
2015-09-06 23:32             ` Dave Chinner
2015-09-07  0:05             ` Davidlohr Bueso
2015-09-07  6:57               ` Peter Zijlstra
2015-09-07 20:45                 ` Linus Torvalds
2015-09-08  6:37                   ` Davidlohr Bueso
2015-09-08 10:05                   ` Peter Zijlstra
2015-09-08 17:45                     ` Linus Torvalds
2015-09-13 10:55             ` [tip:locking/core] locking/qspinlock/x86: Fix performance regression under unaccelerated VMs tip-bot for Peter Zijlstra
2015-09-04  7:39   ` [4.2, Regression] Queued spinlocks cause major XFS performance regression Peter Zijlstra
2015-09-04  8:12     ` Dave Chinner
2015-09-04 11:32       ` Peter Zijlstra
2015-09-04 22:03         ` Dave Chinner
2015-09-06 23:47         ` Dave Chinner
2015-09-10  2:09           ` Waiman Long [this message]
     [not found]         ` <CAC=cRTOraeOeu3Z8C1qx6w=GMSzD_4VevrEzn0mMhrqy=7n3wQ@mail.gmail.com>
     [not found]           ` <56094F05.4090809@hpe.com>
2015-09-29  0:47             ` huang ying
2015-09-29  2:57               ` Waiman Long
2015-09-10  2:01 ` Waiman Long

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=55F0E650.1030207@hpe.com \
    --to=waiman.long@hpe.com \
    --cc=Waiman.Long@hp.com \
    --cc=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /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).