On 12/15/25 09:55, Chao Yu via Linux-f2fs-devel wrote: > On 12/12/25 21:52, Yongpeng Yang wrote: >> From: Yongpeng Yang <[email protected]> >> >> For readahead, if the current readahead window is smaller than the extent >> size, expand the window so that larger bios can be issued and improve >> overall read performance. > > Yongpeng, > > Do you have any numbers to reveal how this patch improves the sequential > read performance?
Yes, the goal is to improve sequential read performance when the readahead window is not aligned with the device optimal I/O size. > > In addition, will we suffer regression for random read case? > *Background* On Android systems, some SoC vendors reduce the readahead window in order to avoid excessive useless readahead. As a result, the readahead window can be smaller than the device optimal I/O size (q->limits.io_opt). When reading large files with dd, the number of read I/Os issued by f2fs_readahead is limited by the readahead window, preventing the device from fully utilizing its performance. *Test setup* 1. Test environment: UFS 4.1 device, q->limits.io_opt is 1 MB 2. Test conditions: a 2 GB file with all extents sized at 2 MB 3. Test variables: the readahead window (read_ahead_kb) and the effective readahead size after adjustment by readahead_expand in f2fs_readahead 4. Test case: dd if=file_2m.dat of=/dev/null bs=512K count=4096, The file page cache is dropped between runs, and the test is repeated 3 times. *Test results* | read_ahead_kb | effective f2fs_readahead window | bandwidth (GB/s)| |---------------|---------------------------------|-----------------| | 512 KB | 512 KB | 2.2 | | 512 KB | 1024KB | 2.6 | | 1024KB | 1024KB | 2.6 | | 1024KB | 2048KB | 3.0 | *Analysis* 1. The first row reflects the commonly used configuration and serves as the baseline. 2. When the readahead window is aligned with the device optimal I/O size, the bandwidth improves by about 18%. 3。 Increasing the effective f2fs_readahead window to 2 MB improves bandwidth by about 36%. *Disscusion* The goal of this patch is to improve sequential read bandwidth when the readahead window is smaller than the device optimal I/O size. Would it make sense to record the end offset of the previous file access in f2fs_read_ahead to determine whether the current read is sequential, and based on that, decide whether to increase the readahead size? Thanks Yongpeng, > Thanks, > >> >> Signed-off-by: Yongpeng Yang <[email protected]> >> --- >> fs/f2fs/data.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >> index c30e69392a62..2e5cbdb7729c 100644 >> --- a/fs/f2fs/data.c >> +++ b/fs/f2fs/data.c >> @@ -2377,6 +2377,17 @@ static int f2fs_mpage_readpages(struct inode *inode, >> map.m_seg_type = NO_CHECK_TYPE; >> map.m_may_create = false; >> >> + if (rac) { >> + loff_t block_in_file; >> + >> + block_in_file = rac->_index; >> + map.m_lblk = block_in_file; >> + map.m_len = max(nr_pages, inode_to_bdi(inode)->ra_pages); >> + if (!f2fs_map_blocks(inode, &map, F2FS_GET_BLOCK_DEFAULT) && >> map.m_len > nr_pages) { >> + readahead_expand(rac, block_in_file << >> F2FS_BLKSIZE_BITS, map.m_len << F2FS_BLKSIZE_BITS); >> + nr_pages = readahead_count(rac); >> + } >> + } >> for (; nr_pages; nr_pages--) { >> if (rac) { >> folio = readahead_folio(rac); > > > > _______________________________________________ > Linux-f2fs-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
