Hi, > Wang Yugui has a workload which would be improved by using large folios. > Until now, we've only created large folios in the readahead path, > but this workload writes without reading. The decision of what size > folio to create is based purely on the size of the write() call (unlike > readahead where we keep history and can choose to create larger folios > based on that history even if individual reads are small). > > The third patch looks like it's an optional extra but is actually needed > for the first two patches to work in the write path, otherwise it limits > the length that iomap_get_folio() sees to PAGE_SIZE. very good test result on 6.4.0-rc2. # just drop ';' in 'if (bytes > folio_size(folio) - offset);' of [PATCH 3/3]. fio -name write-bandwidth -rw=write -bs=1024Ki -size=32Gi -runtime=30 -iodepth 1 -ioengine sync -zero_buffers=1 -direct=0 -end_fsync=1 -numjobs=4 -directory=/mnt/test fio WRITE: bw=7655MiB/s (8027MB/s). Now it is the same as 5.15.y Best Regards Wang Yugui (wangyugui@xxxxxxxxxxxx) 2023/05/21 > Matthew Wilcox (Oracle) (3): > filemap: Allow __filemap_get_folio to allocate large folios > iomap: Create large folios in the buffered write path > iomap: Copy larger chunks from userspace > > fs/gfs2/bmap.c | 2 +- > fs/iomap/buffered-io.c | 32 ++++++++++++++++++------------ > include/linux/iomap.h | 2 +- > include/linux/pagemap.h | 29 ++++++++++++++++++++++++--- > mm/filemap.c | 44 ++++++++++++++++++++++++++++------------- > mm/folio-compat.c | 2 +- > mm/readahead.c | 13 ------------ > 7 files changed, 78 insertions(+), 46 deletions(-) > > -- > 2.39.2
