Re: [PATCH] smb3: add rasize mount parameter to improve performance of readahead

[Shyam Prasad N <nspmangalore@gmail.com>]

Hi Matthew,

Sorry for the late reply. Still catching up on my emails.
No. I did not see read-aheads ramping up with random reads, so I feel
we're okay there with or without this patch.

Although ideally, I feel that we (cifs.ko) should be able to read in
larger granular "chunks" even for small reads, in expectation that
surrounding offsets will be read soon.
This is especially useful if the read comes from something like a loop
device backed file.

Is there a way for a filesystem to indicate to the mm/readahead layer
to read in chunks of N bytes? Even for random workloads? Even if the
actual read is much smaller?
I did some code reading of mm/readahead.c and understand that if the
file is opened with fadvise flag of FADV_RANDOM, there's some logic to
read in chunks. But that seems to work only if the actual read size is
bigger.

Regards,
Shyam

On Mon, Apr 26, 2021 at 5:25 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, Apr 26, 2021 at 10:22:27AM +0530, Shyam Prasad N wrote:
> > Agree with this. Was experimenting on the similar lines on Friday.
> > Does show good improvements with sequential workload.
> > For random read/write workload, the user can use the default value.
>
> For a random access workload, Linux's readahead shouldn't kick in.
> Do you see a slowdown when using this patch with a random I/O workload?
>


-- 
Regards,
Shyam