Re: [f2fs-dev] [PATCH 4/4] f2fs: Run f2fs_write_end_io() asynchronously

Chao Yu via Linux-f2fs-devel <[email protected]>
Newsgroups net.sourceforge.lists.linux-f2fs-devel
Message-ID <[email protected]>
On 6/11/26 02:27, Bart Van Assche wrote:
> On 6/10/26 5:14 AM, Chao Yu wrote:
>> On 5/29/26 05:20, Bart Van Assche wrote:
>>> +    /*
>>> +     * SZ_16K restricts the time spent on completing writes to about 150
>>> +     * microseconds on an Arm Cortex-A520 core.
>>> +     */
>>> +    sbi->max_atc_write_bio_size = SZ_16K;
>>
>> Actually, I don't see this problem before, can we disable this by default, and
>> only enable for your case via sysfs?
> 
> The new behavior should be the default because interrupt handlers should
> complete quickly.
> 
> F2FS is primarily used on Android systems. On an Android system spending
> too much time in interrupt context can have the following consequences:
> * User interface stuttering and frame drops (jank).
> * Audio glitches.
> * Application not responding (ANR).
> * Connectivity degradation. Interfaces like Wi-Fi and Bluetooth depend
>    on fast interrupt handling.

Bart,

Yes, agreed, and I can understand that.

Actually, I'm worry about whether there is potential performance regression
caused by enabling this by default, also a little bit concern about the affection
for PC|laptop scenario which is used by individual user.

One example is commit 91b587ba79e1 ("f2fs: Introduce linear search for dentries"),
lots of following extra works were done to fix the performance regression issue it
caused.

What do you think of separating functionality patches and enabling by default path?
I think we can apply functionality patches first.

Thanks,

> 
>>> +    ATTR_LIST(max_atc_write_bio_size),
>>
>> We need to update Documentation/ABI/testing/sysfs-fs-f2fs as well.
> 
> Will do.
> 
> Thanks,
> 
> Bart.



_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.