-
Notifications
You must be signed in to change notification settings - Fork 492
Description
When passing POSIX_FADV_WILLNEED as advice option to io_uring_prep_fadvise API, the man page states:
POSIX_FADV_WILLNEED
The specified data will be accessed in the near future.
POSIX_FADV_WILLNEED initiates a nonblocking read of the
specified region into the page cache. The amount of data
read may be decreased by the kernel depending on virtual
memory load.
However, it looks like there is no mechanism to initiate non-blocking reads and hence the "len" argument passed to the API isn't honored. This seems to be the same even when using posix_fadvise() and readahead() system calls as well.
Looking at the kernel code it looks like the size passed from these syscalls is always capped to the size of the block device read-ahead setting here, thereby the syscall immediately exits without actually kicking off the reads for the full requested length.
It looks like none of the filesystems also defer the work to kernel worker threads as well.
Any reason why we cannot defer the work to kernel worker threads ?
The workaround I see is to use io_uring_pread_read() with IOSQE_ASYNC flag which will forcefully push the request to async task work.