linux-kernel - Re: [LKP] [page cache] eb797a8ee0: vm-scalability.throughput -16.5% 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 14 Nov 2018 06:17:13 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     kernel test robot <rong.a.chen@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>, lkp@...org
Subject: Re: [LKP] [page cache]  eb797a8ee0:  vm-scalability.throughput
 -16.5% regression

On Wed, Nov 14, 2018 at 05:22:42PM +0800, kernel test robot wrote:
> FYI, we noticed a -16.5% regression of vm-scalability.throughput due to commit:
> commit: eb797a8ee0ab4cd03df556980ce7bf167cadaa50 ("page cache: Rearrange address_space")
> 
> in testcase: vm-scalability
> on test machine: 80 threads Skylake with 64G memory
> with following parameters:
> 
> 	runtime: 300s
> 	test: small-allocs
> 	cpufreq_governor: performance

Thanks for the report.  I am surprised by it, because I can't see what
could have caused this.  On a 64-bit system (which your test is using),
here's the effect of that patch:

gfp_mask moves from being with private_lock up into a hole adjacent
to i_mmap_writable.
wb_err moves from the end of the array up to be with private_lock.
address_space shrinks by 8 bytes.

Hmm.  Might the shrinking be the problem?  Something in struct inode is
now split across two cachelines, or is no longer in the same cacheline
as something else?

I'm at Plumbers this week, so I don't have much time to investigate,
but this regression is very important to me and I shall dig into this
when I can.  It's OK to revert this commit in the meantime; nothing
depends on it yet.

> In addition to that, the commit also has significant impact on the following tests:
> 
> | testcase: change | unixbench: unixbench.score 20.9% improvement                         |

Huh.  If we had to choose, would a 20.9% improvement in unixbench be more
important than a 16.5% penalty to will-it-scale?