linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Jeuk Kim <jeuk20.kim@gmail.com>
To: Chao Yu <chao@kernel.org>, jaegeuk@kernel.org
Cc: hyenc.jeong@samsung.com, jieon.seol@samsung.com,
	gyusun.lee@samsung.com, wone.jung@samsung.com,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, d_hyun.kwon@samsung.com,
	jeuk20.kim@samsung.com, jaemyung.lee@samsung.com
Subject: Re: [f2fs-dev] [PATCH] f2fs: serialize writeback for inline-crypto inodes
Date: Tue, 21 Oct 2025 16:12:18 +0900	[thread overview]
Message-ID: <a4bcf251-e1cf-47ef-84df-5c43b2b288c0@gmail.com> (raw)
In-Reply-To: <75d0a52d-1662-45f9-ab67-909b906004b3@kernel.org>


On 10/21/2025 3:51 PM, Chao Yu wrote:
> On 10/21/25 11:33, Jeuk Kim wrote:
>> On 10/16/2025 7:12 PM, Chao Yu wrote:
>>> On 10/16/2025 1:16 PM, Jeuk Kim wrote:
>>>> From: Jeuk Kim <jeuk20.kim@samsung.com>
>>>>
>>>> Inline encryption derives DUN from <inode, file offset>,
>>>> so bios from different inodes can't merge. With multi-threaded
>>>> buffered O_SYNC writes where each thread writes to its own file,
>>>> 4KiB-per-page LBA allocation interleaves across inodes and
>>>> causes bio split. Serialize writeback for fscrypt inline-crypto
>>>> inodes via __should_serialize_io() to keep foreground writeback
>>>> focused on one inode and avoid split.
>>>>
>>>> Test: fio --name=wb_osync --rw=write --bs=1M \
>>>>         --time_based=1 --runtime=60s --size=2G \
>>>>         --ioengine=psync --direct=0 --sync=1 \
>>>>         --numjobs=8 --thread=1 --nrfiles=1 \
>>>>         --filename_format='wb_osync.$jobnum'
>>>>
>>>> device: UFS
>>>>
>>>> Before -
>>>>     write throughput: 675MiB/s
>>>>     device I/O size distribution (by count, total 1027414):
>>>>       4 KiB:  923139 (89.9%)
>>>>       8 KiB:  84798 (8.3%)
>>>>       ≥512 KiB: 453 (0.0%)
>>>>
>>>> After -
>>>>     write throughput: 1760MiB/s
>>>>     device I/O size distribution (by count, total 231750):
>>>>       4 KiB:  16904 (7.3%)
>>>>       8 KiB:  72128 (31.1%)
>>>>       ≥512 KiB: 118900 (51.3%)
>>>>
>>>> Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
>>>> ---
>>>>    fs/f2fs/data.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>> index ef38e62cda8f..ae6fb435d576 100644
>>>> --- a/fs/f2fs/data.c
>>>> +++ b/fs/f2fs/data.c
>>>> @@ -3217,6 +3217,8 @@ static inline bool __should_serialize_io(struct inode *inode,
>>>>          if (f2fs_need_compress_data(inode))
>>>>            return true;
>>>> +    if (fscrypt_inode_uses_inline_crypto(inode))
>>>> +        return true;
>>>>        if (wbc->sync_mode != WB_SYNC_ALL)
>>>>            return true;
>>>>        if (get_dirty_pages(inode) >= SM_I(F2FS_I_SB(inode))->min_seq_blocks)
>>> Jeuk,
>>>
>>> Can you please try tuning /sys/fs/f2fs/<dev>/min_seq_blocks to see whether it
>>> can achive the goal?
>>>
>>> Thanks,
>>>
>> Hi Chao,
>>
>> Thanks a lot for the suggestion.
>> I tried tuning `/sys/fs/f2fs/<dev>/min_seq_blocks` as you mentioned, and it also achieved similar performance improvement on my setup.
>>
>> Your approach looks cleaner and better than the one I proposed.
>>
>>  From what I see, even after reducing this value from the default (2MB) to 512 KB on my local system, there doesn’t seem to be any noticeable performance drop or other side effects.
>> Do you see any possible downsides with lowering this value that I might have missed?
> Hi Jeuk,
>
> We're using sbi->writepages to serialize large IOs, once you tuned default
> value from 2MB to 512KB, in Android, there are threads issue [512K, 2M)
> sized IOs, they will join into racing on grabbing the .writepages lock,
> I guess that will cause potential performance regression, right?

That's right, that could happen.

I’ll run some tests to check that, including a few other cases that 
might be affected.
I’ll share the results here if I find anything noticeable.

Thanks for your help!

> Thanks,
>


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

      reply	other threads:[~2025-10-21  7:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16  5:16 [f2fs-dev] [PATCH] f2fs: serialize writeback for inline-crypto inodes Jeuk Kim
2025-10-16 10:12 ` Chao Yu via Linux-f2fs-devel
2025-10-21  3:33   ` Jeuk Kim
2025-10-21  6:51     ` Chao Yu via Linux-f2fs-devel
2025-10-21  7:12       ` Jeuk Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4bcf251-e1cf-47ef-84df-5c43b2b288c0@gmail.com \
    --to=jeuk20.kim@gmail.com \
    --cc=chao@kernel.org \
    --cc=d_hyun.kwon@samsung.com \
    --cc=gyusun.lee@samsung.com \
    --cc=hyenc.jeong@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=jaemyung.lee@samsung.com \
    --cc=jeuk20.kim@samsung.com \
    --cc=jieon.seol@samsung.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wone.jung@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).