On Mon, May 16, 2022 at 11:52:39AM +0200, Jan Kara wrote: > * This way processes calling discard / zeroout can easily starve process > wanting to do read which does not seem ideal. Somewhat related is that I > know that Christoph wanted to modify how we use filemap_invalidate_lock() > so that huge zeroouts performed by actually writing zeros will not block > readers for ages and this seems to be going in somewhat opposite direction > favoring writers even more. > * I suspect this is going to upset lockdep (and lock owner tracking for the > purposes of spinning) pretty badly because the lock owner may be returning > to userspace without unlocking the lock. Yes to all of the above. I think we need to just pick a smaller defauly zeroout size (and make that tunable) to avoid holding the lock over really long operations. Or turn the invalidate lock into a range lock..
