On Thu, Sep 17, 2020 at 03:48:04PM +0100, Christoph Hellwig wrote: > On Thu, Sep 17, 2020 at 06:42:19AM -0400, Brian Foster wrote: > > That wouldn't address the latency concern Dave brought up. That said, I > > have no issue with this as a targeted solution for the softlockup issue. > > iomap_finish_ioend[s]() is common code for both the workqueue and > > ->bi_end_io() contexts so that would require either some kind of context > > detection (and my understanding is in_atomic() is unreliable/frowned > > upon) or a new "atomic" parameter through iomap_finish_ioend[s]() to > > indicate whether it's safe to reschedule. Preference? > > True, it would not help with latency. But then again the latency > should be controlled by the writeback code not doing giant writebacks > to start with, shouldn't it? > > Any XFS/iomap specific limit also would not help with the block layer > merging bios. /me hasn't totally been following this thread, but iomap will also aggregate the ioend completions; do we need to cap that to keep latencies down? I was assuming that amortization was always favorable, but maybe not? --D
