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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 09 Sep 2015 22:01:54 -0400
From:	Waiman Long <waiman.long@....com>
To:	Dave Chinner <david@...morbit.com>
CC:	linux-kernel@...r.kernel.org, peterz@...radead.org,
	Waiman.Long@...com, torvalds@...ux-foundation.org
Subject: Re: [4.2, Regression] Queued spinlocks cause major XFS performance
 regression

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/