Lukas Czerner <lczerner@xxxxxxxxxx> writes: >> The thing we do is a best effort thing that more or less guarantees that if >> you do say buffered IO and direct IO after that, it will work reasonably. >> However if direct and buffered IO can race, bad luck for your data. I don't >> think we want to sacrifice any performance of AIO DIO (and offloading of >> direct IO completion to a workqueue so that we can do invalidation costs >> noticeable mount of performance) for supporting such usecase. > > What Jeff proposed would sacrifice performance for the case where AIO > DIO write does race with buffered IO - the situation we agree is not ideal > and should be avoided anyway. For the rest of AIO DIO this should have no > effect right ? If true, I'd say this is a good effort to make sure we do > not have disparity between page cache and disk. Exactly. Jan, are you concerned about impacting performance for mixed buffered I/O and direct writes? If so, we could look into restricting the process context switch further, to just overlapping buffered and direct I/O (assuming there are no locking issues). Alternatively, since we already know this is racy, we don't actually have to defer I/O completion to process context. We could just complete the I/O as we normally would, but also queue up an invalidate_inode_pages2_range work item. It will be asynchronous, but this is best effort, anyway. As Eric mentioned, the thing that bothers me is that we have invalid data lingering in the page cache indefinitely. Cheers, Jeff
