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

[Alexander Indenbaum]

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.

> 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 :)

>
> Regards,
>
> James Roper
>
> Sent from my iPhone

Thank you for your help,
Alexander Indenbaum

>
> On 16/09/2008, at 2:17, Alexander Indenbaum  wrote:
>
>> Hello,
>>
>> I'm working with two kinds of embedded Linux boxes powered by 2.4
>> kernel and cifs  1.20c connected to Windows CIFS server via 100Mbps
>> Ethernet switch. Our usage pattern is sequential read of large files
>> from CIFS shares ("streaming"). I'm using  simple "time dd
>> if=CIFS_FILE of=/dev/null" benchmark to measure read performance. Here
>> are results:
>>
>> CPU strength/BogoMIPS        Read Throughput/Mbps
>> 266                                       5
>> 2988                                     14.5
>>
>> As you see, read performance is heavily influenced by CPU strength :)
>> I'm looking for a ways to improve read performance especially on  weak
>> 266 BogoMIPS box. After doing some reading I started to believe the
>> best way to do so is to implement some kind of read-ahead mechanism. I
>> saw 2.5 kernel patch by James Roper doing so over vfs_readpages
>> interface - http://marc.info/?l=linux-cifs-client&m=112665626721358
>> I've tried to integrate the patch but 2.4 kernel does not have
>> vfs_readpages interface :(.
>>
>> So what do you think? Is it possible to implement CIFS read-ahead over
>> 2.4 VFS? How?
>> Maybe other ideas for performance optimization?
>>
>> Thank you for your help,
>> Alexander Indenbaum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save-copy-receive.patch
Type: text/x-diff
Size: 22647 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080916/61b44ae0/save-copy-receive-0001.bin