[linux-cifs-client] Re: sequential read performance - read ahead ?

[Jeff Layton]

On Tue, 16 Sep 2008 19:43:43 +0300
"Alexander Indenbaum" <alexander.indenbaum at gmail.com> wrote:

> Hello James,
> 
> Thank you for your response! See my comments bellow.
> 
> On Tue, Sep 16, 2008 at 2:55 AM, James Roper <u3205097 at anu.edu.au> wrote:
> > Hi Alexander,
> >
> > The concept behind read ahead is that you can minimise the penalty caused by the in flight time as the data is traveling between the client and the server, by doing other things while you're waiting, eg by sending more requests. If it's the clients CPU speed that is slowing you down, then it's likely that the client isn't spending much time waiting in comparison to the amount of time it's spending processing, so the in flight time would not be that large a penalty.  So reading ahead probably won't help you that much. Additionally, it would be no trivial task to implement read ahead in the cifs client in a 2.4 kernel, you would have to do your own sequential read detection, caching of read ahead pages between vfs reads, and cleanup of unread pages.
> >
> 
> In my test environment I do not see that slow CPU is fully utilized
> during CIFS transfers. Actually the CPU has a lot of spare cycles. I
> suppose that we see degradation of sequential read performance on
> slow CPU because there is no TCP like "sliding window" and
> request<->response cycle takes longer due to slugish CPU. After all
> one slow CPU tick takes as long as modern CPU 10 ticks :).  So this
> way neither CPU nor network link are fully utilized. That's why I
> still hope "read-ahead" could improve the read throughput. I have
> almost no experience in Linux VM/VFS so I'm not really sure how to
> implement file's memory page "pre-fetch". In case I get the
> "pre-fetched" page from the server that application has not yet issued
> cifs_readpage() for it. How can I allocate new page and associate with
> the file, so VM/VFS will not try to fetch it over network again? Any
> pointer to similar code will be appreciated.
> 

It sounds like you're trying to throw a solution at a problem you don't
yet fully understand. Nothing wrong with that -- sometimes you get
lucky, but performance problems are usually tracked down through hard
investigation. You might want to spend more time tracking down where
the bottleneck is before you implement a readahead scheme. It's quite
possible you'll end up with some great readahead code that doesn't help
at all.

> > I'm not sure about other performance improvements, it's been a long time since I've looked at cifs vfs, but there may be some memcopys that can be eliminated, that has the potential to make a significant difference.
> 
> Thank you for this idea. Please see the attached "very raw and
> untested" patch against 1.20c. It should save memcpy of data on
> receive path. Unfortunately, I did not notice any significant
> performance improvement :)
> 

Yikes! 1.20c is pretty ancient stuff (2004, I think?)

Steve French has some intermittently updated tarballs of newer cifs
code that is backported to older kernels. I think this is the latest
one:

ftp://ftp.samba.org/pub/samba/cifs-cvs/cifs-1.50c.tar.gz

...there are earlier ones in the same directory too.

You may want to try building that for your kernel and seeing if it
helps before you start trying to implement anything new. I've never
done a backport of CIFS to a 2.4 kernel though -- it may take some
significant work (though probably less than implementing your own
readahead scheme).

-- 
Jeff Layton <jlayton at redhat.com>