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

[Colin Ian King]

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.

[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
>