On Mon, Jul 10, 2023 at 02:02:44PM +0100, Matthew Wilcox (Oracle) wrote: > Commit ebb7fb1557b1 limited the length of ioend chains to 4096 entries > to improve worst-case latency. Unfortunately, this had the effect of > limiting the performance of: > > 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 When you say performance, do you mean overall throughput / IOPS / latency or all? And who noticed it / reported it? The above incantation seems pretty specific so I'm curious who runs that test and what sort of work flow is it trying to replicate. > The problem ends up being lock contention on the i_pages spinlock as we > clear the writeback bit on each folio (and propagate that up through > the tree). By using larger folios, we decrease the number of folios > to be processed by a factor of 256 for this benchmark, eliminating the > lock contention. Implied here seems to suggest that the associated cost for the search a larger folio is pretty negligable compared the gains of finding one. That seems to be nice but it gets me wondering if there are other benchmarks under which there is any penalties instead. Ie, is the above a microbenchmark where this yields good results? > It's also the right thing to do. This is a project that has been on > the back burner for years, it just hasn't been important enough to do > before now. Commit ebb7fb1557b1 (xfs, iomap: limit individual ioend chain lengths in writeback") dates back to just one year, and so it gets me wondering how a project in the back burner for years now finds motivation for just a one year old regression. What was the original motivation of the older project dating this effort back to its inception? Luis
