Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations

[Gao Xiang <hsiangkao@linux.alibaba.com>]

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