On 05/26, Christoph Hellwig wrote: > On Tue, May 26, 2026 at 09:14:52AM -0700, Bart Van Assche wrote: > > On 5/26/26 6:42 AM, Theodore Tso wrote: > > > It seems... surprising that the additional I/O operations are actually > > > throttloing UFS device bandwidth by 2x (4GB/s vs 2GB/s). Have you dug > > > into why this is happening, and whether there is anything that can be > > > optimized below the file system? > > The layers below the filesystem (block, SCSI, UFS) is what I'm > > responsible for in the Pixel team and I can assure you that these are > > highly optimized. > > > > Since the transfer size used in Jaegeuk's tests is much larger than 4 > > KiB, how many CPU cycles are used per IO by the layers below the > > filesystem is not limiting the transfer bandwidth. > > I'm honestly not sure what discussion we have here. Larger I/O is > pretty much always more efficient. If you submit smaller I/O you > need more merging to build it back up larger, and more I/Os.
F2FS merges bios before submit_bio, regardless of small or large folios, since the block addresses are consecutive. So, I think IO subsystem was working in full speed. > > Which is exaxtly why we need large folio support everywhere, as it > makes a huge difference in I/O performance. > > > > _______________________________________________ > 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
