On Wed, Jun 25, 2025 at 09:14:51PM +0530, Kundan Kumar wrote: > > > > Makes sense. It would be good to test this on a non-SMP machine, if > > you can find one ;) > > > > Tested with kernel cmdline with maxcpus=1. The parallel writeback falls > back to 1 thread behavior, showing nochange in BW. > > - On PMEM: > Base XFS : 70.7 MiB/s > Parallel Writeback XFS : 70.5 MiB/s > Base EXT4 : 137 MiB/s > Parallel Writeback EXT4 : 138 MiB/s > > - On NVMe: > Base XFS : 45.2 MiB/s > Parallel Writeback XFS : 44.5 MiB/s > Base EXT4 : 81.2 MiB/s > Parallel Writeback EXT4 : 80.1 MiB/s > > > > > Please test the performance on spinning disks, and with more filesystems? > > > > On a spinning disk, random IO bandwidth remains unchanged, while sequential > IO performance declines. However, setting nr_wb_ctx = 1 via configurable > writeback(planned in next version) eliminates the decline. > > echo 1 > /sys/class/bdi/8:16/nwritebacks > > We can fetch the device queue's rotational property and allocate BDI with > nr_wb_ctx = 1 for rotational disks. Hope this is a viable solution for > spinning disks?
Sounds good to me, spinning rust isn't known for iops. Though: What about a raid0 of spinning rust? Do you see the same declines for sequential IO? --D > - Random IO > Base XFS : 22.6 MiB/s > Parallel Writeback XFS : 22.9 MiB/s > Base EXT4 : 22.5 MiB/s > Parallel Writeback EXT4 : 20.9 MiB/s > > - Sequential IO > Base XFS : 156 MiB/s > Parallel Writeback XFS : 133 MiB/s (-14.7%) > Base EXT4 : 147 MiB/s > Parallel Writeback EXT4 : 124 MiB/s (-15.6%) > > -Kundan > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
