Hi Marek, great article as usual. > (2) Pre-warm the disk cache with posix_fadvise(2) and hope for the best. Just as an aside, there is also the option of mlo

Hi Marek, great article as usual. > (2) Pre-warm the disk cache with posix_fadvise(2) and hope for the best. Just as an aside, there is also the option of mlock(2) to improve this technique as implemented in the flash webserver (https://www.usenix.org/legacy/events/usenix99/full_papers/pai/pai.pdf https://www.usenix.org/legacy/events/usenix99/full_papers/pa...). Also some people use vmtouch (https://hoytech.com/vmtouch/ https://hoytech.com/vmtouch/) for similar things. Regarding this new interface, the LWN article says: > AIO poll operations always operate in the "one-shot" mode; once a poll notification has been generated, a new IOCB_CMD_POLL IOCB must be submitted for that file descriptor if further notifications are needed. Does this mean that in the (I think fairly common) case of wanting to persist a poll indefinitely until (for example) a socket is closed, with this new interface you will need to re-issue a poll after every IO operation? If so would that mitigate some/any of the performance benefit you described? Lastly just wanted to point out the following research in case you haven't seen it before (and the various other designs it cites): https://www.usenix.org/legacy/event/atc11/tech/final_files/Soares.pdf https://www.usenix.org/legacy/event/atc11/tech/final_files/S... Cheers!