On 7 Jan 2020, at 12:42, Christoph Hellwig wrote: > On Fri, Dec 13, 2019 at 01:32:10AM +0000, Chris Mason wrote: >> They just have different tradeoffs. O_DIRECT actively blows away >> caches >> and can also force writes during reads, making RWF_UNCACHED a more >> natural fit for some applications. There are fewer surprises, and >> some >> services are willing to pay for flexibility with a memcpy. In >> general, >> they still want to do some cache management because it reduces p90+ >> latencies across the board, and gives them more control over which >> pages >> stay in cache. > > We can always have a variant of O_DIRECT that doesn't do that and > instead check if data was in the cache and then also copy / from to > it in that case. I need some time to actually look through this > series, > so it might be pretty similar to the implementation, but if defined > the right way it could be concurrent for at least the fast path of no > cached pages. Yeah, I really do think we can end up with a fairly unified solution through iomap: * Allowing concurrent writes (xfs DIO does this now) * Optionally doing zero copy if alignment is good (btrfs DIO does this now) * Optionally tossing pages at the end (requires a separate syscall now) * Supporting aio via io_uring We could just call this O_DIRECT, but I like RWF_UNCACHED as a way to avoid surprises for people that know and love the existing O_DIRECT semantics. -chris
