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

[Seth Forshee]

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 ...).

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.

Thanks,
Seth