On 2023/3/1 12:40, Matthew Wilcox wrote:
On Wed, Mar 01, 2023 at 12:18:30PM +0800, Gao Xiang wrote:
For example, most cloud storage devices are doing read-ahead to try to
anticipate read requests from the VM. This can interfere with the
read-ahead being done by the guest kernel. So being able to tell
cloud storage device whether a particular read request is stemming
from a read-ahead or not. At the moment, as Matthew Wilcox has
pointed out, we currently use the read-ahead code path for synchronous
buffered reads. So plumbing this information so it can passed through
multiple levels of the mm, fs, and block layers will probably be
needed.
It seems that is also useful as well, yet if my understanding is correct,
it's somewhat unclear for me if we could do more and have a better form
compared with the current REQ_RAHEAD (currently REQ_RAHEAD use cases and
impacts are quite limited.)
I'm pretty sure the Linux readahead algorithms could do with some serious
tuning (as opposed to the hacks the Android device vendors are doing).
Outside my current level of enthusiasm / knowledge, alas. And it's
hard because while we no longer care about performance on floppies,
we do care about performance from CompactFlash to 8GB/s NVMe drives.
I had one person recently complain that 200Gbps ethernet was too slow
for their storage, so there's a faster usecase to care about.
Yes, we might have a chance to revisit the current readahead algorithm
towards the modern storage devices. I understand how the current
readahead works but don't have enough slots to analyse the workloads
and investigate more, also such heuristic stuff can have pro-and-con
sides all the time.
As a public cloud vendor, it becomes vital to change since some users
just would like to care about the corner cases compared with other
competitors.
Thanks,
Gao Xiang
