[PATCH 0/2][SRU][E] improve ext4 performance with revert of a reverted ext4 fix

[Seth Forshee]

On Thu, Oct 03, 2019 at 05:20:51PM +0100, Colin Ian King wrote:
> On 03/10/2019 16:44, Seth Forshee wrote:
> > On Thu, Oct 03, 2019 at 02:10:02PM +0100, Colin King wrote:
> > > From: Colin Ian King <colin.king at canonical.com>
> > > 
> > > BugLink: https://bugs.launchpad.net/bugs/1846486
> > > 
> > > == SRU Justification Eoan ==
> > > 
> > > Now that 5.4 contains a fix to the bootup regression due to the
> > > lack of entropy at bootable we should apply this fix and also
> > > revert the revert of commit
> > > "Revert "ext4: make __ext4_get_inode_loc plug"".
> > > 
> > > == Fix ==
> > > 
> > > So, to clarify, apply the two upstream 5.4-rc commits:
> > > 
> > > commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> > > Author: Linus Torvalds <torvalds at linux-foundation.org>
> > > Date: Sat Sep 28 16:53:52 2019 -0700
> > > 
> > >      random: try to actively add entropy rather than passively wait for it
> > > 
> > > commit 02f03c4206c1b2a7451d3b3546f86c9c783eac13
> > > Author: Linus Torvalds <torvalds at linux-foundation.org>
> > > Date: Sun Sep 29 17:59:23 2019 -0700
> > > 
> > >      Revert "Revert "ext4: make __ext4_get_inode_loc plug""
> > > 
> > > I've benchmarked the Eoan kernel with these two patches and found theo
> > > following speed improvements on an i7-3770 CPU @ 3.40GHz with 8GB and a
> > > WDC WD10EZEX-21WN4A HDD (7200RPM, 64MB cache).
> > > 
> > > git grep of the kernel: 0.14%
> > > building fwts: 0.40%
> > > build stress-ng 0.45%
> > > tar up kernel source: 7.6%
> > > boot time of eoan cloud image: 10.5%
> > > 
> > > So I think the speed improvements justifies the SRU.
> > > 
> > > == Regression potential ==
> > > 
> > > Minor change to ext4, which has been regression tested, so risk here is
> > > small. The entropy change will alter the random number generation, but
> > > I believe this does not change the cryptographical security of the random
> > > numbers being generated, so think this change is not security risk.
> > > 
> > > Originally the ext4 change caused boot time user space regressions
> > > because of the entropy change of this fix, but the random fix addresses
> > > this, so I believe this risk is now zero.
> > 
> > I have a couple of questions.
> > 
> > Do any of our supported architectures lack a CPU cycle counter? It
> > sounds like if they do, they will not benefit from the entropy patch and
> > thus will suffer from the original regression (granted we'll get this in
> > 5.4 no mater what ...).
> 
> According to wikipedia [1]:
> 
> 1. ARMv7[12] and ARMv8[13] architectures provide a generic counter which
> counts at a constant frequency.
> 2. PowerPC provides the 64-bit TBR
> 3. s390x has a cycle counter instruction
> 4. x86 TSC has available in all CPUs since Pentium.

Great, thanks!

> 
> [1] https://en.wikipedia.org/wiki/Time_Stamp_Counter
> > 
> > Is this patch something you're looking to get into the -release kernel?
> > Given that it's for performance, it doesn't strike me as
> > release-critical.
> 
> It's not release critical. Just nice to have.
> 
> > 
> > Thanks,
> > Seth
> > 
>