Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1431396 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [LKP] [lkp] [dcache_{readdir, dir_lseek}() users] 4e82901cd6:  reaim.jobs_per_min -49.1% regression Thorsten Leemhuis <regressions@leemhuis.info> - 2016-06-26 12:00 +0200
    Re: [LKP] [lkp] [dcache_{readdir, dir_lseek}() users] 4e82901cd6:  reaim.jobs_per_min -49.1% regression Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-26 19:20 +0200
      Re: [LKP] [lkp] [dcache_{readdir, dir_lseek}() users] 4e82901cd6:  reaim.jobs_per_min -49.1% regression Al Viro <viro@ZenIV.linux.org.uk> - 2016-06-26 20:10 +0200
        Re: [LKP] [lkp] [dcache_{readdir, dir_lseek}() users] 4e82901cd6:  reaim.jobs_per_min -49.1% regression Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-26 23:30 +0200

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

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@intel.com> 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

[toc] | [next] | [standalone]

#1431548

On Sun, Jun 26, 2016 at 2:50 AM, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Al, what's the status here? This made it on my 4.7 regressions report
> due to the "regression" keyword in the subject.

I don't think the tmpfs locking is going to get changed for 4.7. This
issue will likely only show up for some very specific microbenchmarks,
and the lockless next_positive one is likely too invasive for this
stage. So the problem is fixable, and not serious enough to worry
about for 4.7.

             Linus

[toc] | [prev] | [next] | [standalone]

#1431551

On Sun, Jun 26, 2016 at 10:13:32AM -0700, Linus Torvalds wrote:
> On Sun, Jun 26, 2016 at 2:50 AM, Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
> >
> > Al, what's the status here? This made it on my 4.7 regressions report
> > due to the "regression" keyword in the subject.
> 
> I don't think the tmpfs locking is going to get changed for 4.7. This
> issue will likely only show up for some very specific microbenchmarks,
> and the lockless next_positive one is likely too invasive for this
> stage. So the problem is fixable, and not serious enough to worry
> about for 4.7.

FWIW, #work.dcache_readdir in vfs.git seems to recover the performance.
Not sure if it's worth pushing right now, but if it ends up the next
cycle stuff, I think it'll be worth Cc:stable.

[toc] | [prev] | [next] | [standalone]

#1431588

On Sun, Jun 26, 2016 at 11:06 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> FWIW, #work.dcache_readdir in vfs.git seems to recover the performance.
> Not sure if it's worth pushing right now, but if it ends up the next
> cycle stuff, I think it'll be worth Cc:stable.

Hmm. I guess that if you're confident enough about it, we might as
well merge it now and avoid the backport and stable headache.

              Linus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web