Hi, Ran into an issue with IOCB_NOWAIT and O_DIRECT, which causes a rather serious performance issue. If IOCB_NOWAIT is set, the generic/iomap iterators check for page cache presence in the given range, and return -EAGAIN if any is there. This is rather simplistic and looks like something that was never really finished. For !IOCB_NOWAIT, we simply call filemap_write_and_wait_range() to issue (if any) and wait on the range. The fact that we have page cache entries for this range does not mean that we cannot safely do O_DIRECT IO to/from it. This series adds filemap_range_needs_writeback(), which checks if we have pages in the range that do require us to call filemap_write_and_wait_range(). If we don't, then we can proceed just fine with IOCB_NOWAIT. The problem manifested itself in a production environment, where someone is doing O_DIRECT on a raw block device. Due to other circumstances, blkid was triggered on this device periodically, and blkid very helpfully does a number of page cache reads on the device. Now the mapping has page cache entries, and performance falls to pieces because we can no longer reliably do IOCB_NOWAIT O_DIRECT. Patch 1 adds the helper, patch 2 uses it for the generic iterators, and patch 3 applies the same to the iomap direct-io code. fs/iomap/direct-io.c | 10 ++++----- include/linux/fs.h | 2 ++ mm/filemap.c | 52 +++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 56 insertions(+), 8 deletions(-) -- Jens Axboe
