Re: [PATCH v4 0/9] Create large folios in iomap buffered write path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux