[linux-cifs-client] Asynchronous readahead limit

[James Roper]

In regards to my earlier email, haven't worked out the bk problem, but
I've done some experimenting with the read ahead requests.  BTW, all
testing that I did of these routines before were connecting directly to
my laptop running Samba 3.  Now, I'm connecting directly to the same
laptop running Windows XP.  XP seems to be a lot slower in general, I
was copying a 181MB file in 22 seconds from samba using synchronous
routines, now I'm copying a 21MB file in 12 seconds from XP.  But
anyway, so copying a 21MB file over 100MB link, 0.5 ms ping time, XP
file server, unmounting and mounting the share between each copy to
ensure caching has no effect:
Synchronous routines, 32 page read ahead (requests 4 pages at a time):
real    0m12.519s
user    0m0.028s
sys     0m0.640s
Asynchronous with 16 page read ahead:
real    0m7.470s
user    0m0.022s
sys     0m0.692s
Asynchronous with 32 page read ahead:
real    0m7.069s
user    0m0.024s
sys     0m0.701s
Asynchronous with 64 page read ahead:
real    0m7.010s
user    0m0.018s
sys     0m0.699s
Asynchronous with 128 page read ahead:
real    0m6.983s
user    0m0.020s
sys     0m0.688s
Asynchronous with 256 page read ahead:
real    0m7.034s
user    0m0.022s
sys     0m0.712s

These results show that 128 pages is marginally better, and by 256 it's
slowing down.  Though, this test probably wasn't that good, I'll have to
design some better tests, with a 20MB file, the bigger the read ahead
size, the less likely it is that it will be fully utilised, because the
read ahead routines in mm/readahead.c start at half of that number, and
then increment up, by the time the file is downloaded it might not have
even reached its peak.  Another consideration is the 1/2 millisecond
ping time.  I don't have any other network environment to test on, but
I'd guess that the results may be a bit more favourable to the larger
read ahead limits if that ping time were greater.  Finally, you'll
notice that these routines exhibit over a 40% speed increase, it seems
windows XP, though slower than samba, handles asynchronous IO really
well compared to its synchronous performance.

Anyone else willing to test these routines?  I'll post the patch once
I've sorted this bitkeeper problem out.

James



James Roper wrote:

> I'm not very familiar with bitkeeper.  I cloned the linux-2.5cifs 
> repositry 2 days ago, I've since merged a 6 month old patch onto it 
> that I made, I then committed it, found some problems, fixed them, and 
> tried to commit again.  The problem is, I keep getting an error saying 
> max pending logs exceeded, commit aborted.  I want to make some 
> improvements, but before I do so, I want to pull the changesets down 
> that have been made in the past few days.  Any ideas?
>
> Anyway, I'm wondering what people thought about how to improve 
> asynchronous read routines.  The two bottle necks at the moment are 
> the fact that no more than 32 pages are ever requested at once, and 
> the maximum cifs buffer size.  The cifs buffer size actually isn't too 
> much of a problem, it means we have to do a bit more processing to 
> prepare the requests to be received, and incurs more overhead on the 
> network as there are more smb headers being transmitted per KB 
> requested.  But the maximum readahead pages could seriously impede 
> high latency to bandwidth ratio networks, because it means we can only 
> read 128KB per round trip cycle.  So on a gigabit network, with a 
> round trip time of 50 milliseconds (there's a few router hops on the 
> corporate intranet to the file server), we could only get a maximum 
> theoretical download speed of 2.2 MB/s, even though a gigabit network 
> should be able to download at speeds closer to 100MB/s.  I think the 
> best way forward is to experiment with increasing that readahead limit 
> to, say 128 pages, ie 512KB.  Even better might be a proc entry to 
> control it, that way different people can test it on different 
> systems.  I could try and increase the cifs buffer size but maybe it's 
> an idea to wait for the write behind increased buffer size to mature, 
> then use that code or similar code.  Any ideas?
>
> James
>

-- 
James Roper
u3205097 at alumni.anu.edu.au
Phone: +61 2 9524 3380      Mobile: +61 438 406 331