On 24.12.20 г. 20:09 ч., Josef Bacik wrote:
> On 12/21/20 2:45 PM, René Rebe wrote:
>> Hey there,
>>
>> as a long time btrfs user I noticed some some things became very slow
>> w/ Linux kernel 5.10. I found a very simple test case, namely extracting
>> a huge tarball like:
>>
>> tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst
>>
>> Why my external, USB3 road-warrior SSD on a Ryzen 5950x this
>> went from ~15 seconds w/ 5.9 to nearly 5 minutes in 5.10, or 2000%
>>
>> To rule out USB, I also tested a brand new PCIe 4.0 SSD, with
>> a similar, albeit not as shocking regression from 5.2 seconds
>> to ~34 seconds or∫~650%.
>>
>> Somehow testing that in a VM did over virtio did not produce
>> as different results, although it was already 35 seconds slow
>> with 5.9.
>>
>> # first bad commit: [38d715f494f2f1dddbf3d0c6e50aefff49519232]
>> btrfs: use btrfs_start_delalloc_roots in shrink_delalloc
>>
>> Now just this single commit does obviously not revert cleanly,
>> and I did not have the time today to look into the rather more
>> complex code today.
>>
>> I hope this helps improve this for the next release, maybe you
>> want to test on bare metal, too.
>>
>
> Alright to close the loop with this, this slipped through the cracks
> because I was doing a lot of performance related work, and specifically
> had been testing with these patches on top of everything
>
> https://lore.kernel.org/linux-btrfs/[email protected]/
>
>
> These patches bring the performance up to around 40% higher than
> baseline. In the meantime we'll probably push this partial revert into
> 5.10 stable so performance isn't sucking in the meantime. Thanks,
For the sake of clarity it's important to note that baseline in this
case is kernel 4.19 (since the original regressions was spotted in 5.0).
There has already been a couple of open interpretations of what this
means e.g 40% better than 5.10, suggesting performance is worse.
>
> Josef
>
