Re: btrfs write-bandwidth performance regression of 6.5-rc4/rc3

["Linux regression tracking (Thorsten Leemhuis)" <regressions@leemhuis.info>]

On 02.08.23 11:26, Christoph Hellwig wrote:
> On Wed, Aug 02, 2023 at 08:04:57AM +0800, Wang Yugui wrote:
>>> And with only a revert of
>>>
>>> "btrfs: submit IO synchronously for fast checksum implementations"?
>>
>> GOOD performance when only (Revert "btrfs: submit IO synchronously for fast
>> checksum implementations") 
> 
> Ok, so you have a case where the offload for the checksumming generation
> actually helps (by a lot).  Adding Chris to the Cc list as he was
> involved with this.

Radio silence from Chris here and on lore in general afaics. Also
nothing new in this thread for more than a week now.

CCing David and Josef, maybe they have an idea what's up here and if
Chris might be afk for longer -- and maybe this can still be fixed
before the 6.5 release.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

>>>> -       if (test_bit(BTRFS_FS_CSUM_IMPL_FAST, &bbio->fs_info->flags))
>>>> +       if ((bbio->bio.bi_opf & REQ_META) && test_bit(BTRFS_FS_CSUM_IMPL_FAST, &bbio->fs_info->flags))
>>>>                 return false;
>>>
>>> This disables synchronous checksum calculation entirely for data I/O.
>>
>> without this fix, data I/O checksum is always synchronous?
>> this is a feature change of "btrfs: submit IO synchronously for fast checksum implementations"?
> 
> It is never with the above patch.
> 
>>
>>> Also I'm curious if you see any differents for a non-RAID0 (i.e.
>>> single profile) workload.
>>
>> '-m single -d single' is about 10% slow that '-m raid1 -d raid0' in this test
>> case.
> 
> How does it compare with and without the revert?  Can you add the numbers?