What this approach does is only read the data for you if it's in the kernel page cache. If it's not it's your responsibility to get it somehow (maybe through a

What this approach does is only read the data for you if it's in the kernel page cache. If it's not it's your responsibility to get it somehow (maybe through a regular read call). Today it does not enqueue a any kind read-ahead. There's a very long history 12+ years of various buffered disk IO, along similar lines of what you're asking (callback, notification). All of them ended up failing to go upstream for a number of reasons 1) pushed too much complexity into the kernel (complicating the regular code paths) 2) caused regressions in performance in sync read/write 3) were based on functionality that the upstream developers did not want (tasklets). With that background of various failed attempts, my approach focuses on a common use case in modern servers: a network pool loop and a disk IO thread thread pool. That's pretty much how everybody works around lack of async disk IO. The big problem with that is additional latency. That latency comes from synchronization (between two threads) and queuing (cached data stuck in queue behind long running requests). My solution tackles that latency by letting us answer in the same network thread if data is cached by the kernel. I tried this using samba (kernel guys like this use case) and I was able to get close to sync like latency / throughput vs. ~23% lower numbers with pure thread pool. I've observed similar numbers in our application as well. Finally, using this you can implement what you're purposing in user-space using a threadpool without giving up to much performance.