Previously, common VM code read up to FILE_CHUNK_SIZE (16KB) of file contents at a time, i.e. an application issuing the read/pread system call would get the return value of max 16KB. The assumption was that applications that submit a larger buffer will notice the partial read and re-read the missing contents.
This assumption worked well for many applications. But Java (in particular, the HotSpot JVM) breaks this assumption, expecting to get the whole requested buffer in one pread syscall. This commit satisfies this assumption by wrapping FUSE read requests into a while loop. Note that this is similar to what's done for FUSE write requests (detected previously, on Python workloads).
Description of the changes
Previously, common VM code read up to FILE_CHUNK_SIZE (16KB) of file contents at a time, i.e. an application issuing the
read/preadsystem call would get the return value of max 16KB. The assumption was that applications that submit a larger buffer will notice the partial read and re-read the missing contents.This assumption worked well for many applications. But Java (in particular, the HotSpot JVM) breaks this assumption, expecting to get the whole requested buffer in one
preadsyscall. This commit satisfies this assumption by wrapping FUSE read requests into a while loop. Note that this is similar to what's done for FUSE write requests (detected previously, on Python workloads).How to test this PR?
Try Java workloads.
This change is