Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression

[Waiman Long]

On 09/04/2015 01:48 AM, Dave Chinner wrote:
> Hi Waiman,
>
> For the first time in months I just turned of spinlock debugging on
> my performance test machine and I just got an unpleasant surprise on
> my standard inode allocation and reclaim test.  I've described this
> test to you before, because it's found regressions in your previous
> lock scaling changes:
>
> http://permalink.gmane.org/gmane.linux.kernel/1768786
>
> This time it is the fsmark run that I use to populate the filesystem
> that is demonstrating a locking regression. I'll asked you before
> if you could add this test to your lock scaling regression test
> suite; please do it this time.
>
> Now, the regression.  With spinlock debugging turned on, the
> performance of my usual XFS inode allocation benchmark using fsmark
> reports performance like this:
>
> FSUse%        Count         Size    Files/sec     App Overhead
>       0      1600000            0     312594.0          9944159
>       0      3200000            0     295668.6         10399679
>       0      4800000            0     279026.1         11397617
> .....
>
> This has been pretty stable for several releases - it varies +/- a
> few percent, but it's pretty much been like this since about 3.2
> when CONFIG_XFS_DEBUG=n, with or without basic spinlock debugging.
>
> When I turned spinlock debugging off on 4.2 to get some perf numbers
> a request from Linus, I got this:
>
> FSUse%        Count         Size    Files/sec     App Overhead
>       0      1600000            0     114143.9          9597599
>       0      3200000            0      95486.9          9460413
>       0      4800000            0      93918.2          9784699
> .

I am sorry that I was on vacation over the past weekend and so was not 
able to respond in a timely manner. As Peter already has a patch to 
address the root cause of this problem. I think this problem is all set.

Cheers,
Longman

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/