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.
