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.
