Re: [LKP] [lkp] [dcache_{readdir, dir_lseek}() users] 4e82901cd6: reaim.jobs_per_min -49.1% regression

[Thorsten Leemhuis]

On 02.06.2016 18:29, Al Viro wrote:
> On Thu, Jun 02, 2016 at 02:28:36PM +0800, Huang, Ying wrote:
>> "Huang, Ying" <ying.huang@xxxxxxxxx> writes:
> 
>> Here is the comparison result with perf profile information.  You can
>> find it via searching 'perf-profile'.
> [snip]
> Looks like this load is hitting the arseloads of contention cases of
> spin_lock() on various ->d_lock inside dcache_readdir().  With exclusive
> lock on directory most of them end up uncontended...
> 
> I'll try to see what can be done there; [â] 
> I'll play with that and post when I get somewhere with it...

Al, what's the status here? This made it on my 4.7 regressions report
due to the "regression" keyword in the subject.

Is commit 64e3f9744bd3989457502ba79c09445a6909aac1 ("lockless
next_positive()") in
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
untested.dcache_readdir supposed to improve the situation? Just
wondering, because I saw this mail
http://article.gmane.org/gmane.linux.kernel/2241911

Or is this regression not important enough to warrant deeper changes and
will hence only get addressed once 4.7 is out?

Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo)
 Thorsten