Re: Kernel 3.0: Instant kernel crash when mounting CIFS (alsocrashes with linux-3.1-rc2

[Jeff Layton]

On Thu, 18 Aug 2011 14:18:15 -0400 (EDT)
Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx> wrote:

> 
> 
> On Thu, 18 Aug 2011, Steve French wrote:
> 
> > If reading files - smbclient (ftp like syntax) should be able to reach
> > wire speeds (assuming the server disk can keep up) and for
> > writing it should be similar (perhaps a little slower but it won't
> > use i/o sizes as large as cifs kernel client).  I would expect
> > smbclient to/copy from Windows to be faster than Windows mount -> Samba.
> >
> > I reached near wirespeeds for GigE with cifs client (writing) to
> > Winodws 2003/2008/r2
> > and Samba - but didn't have fast enough disks to test 10GigE although I expect
> > very good performance with that if you have fast enough server disks (and
> > am willing to put performance patches in, if you detect additional
> > changes that we should make for 10GigE - in particular allowing
> > more than 50 simultaneous requests).
> >
> > If the registry fix for Windows 7 is in place (or if you copy to
> > WIndows 2008, Windows 2003, WIndows 2008r2) -
> > cifs kernel client is probably slightly faster for writes than alternatives,
> > smbclient much faster for reads.
> >
> > If going the other direction (Windows client copying to/from Samba server) -
> > Samba 3.6 (server) with SMB2 support
> > turned on - is going to be faster than most alternatives.
> 
> Hi,
> 
> Downloading from an FTP Server on the windows machine:
> 
> <--- 150 Connection accepted
> `file' at 418873344 (24%) 145.58M/s eta:9s [Receiving data]
> `file' at 735510528 (42%) 162.93M/s eta:6s [Receiving data]
> `file' at 1357185024 (78%) 172.89M/s eta:2s [Receiving data]
> <--- 226 Transfer OK 
> ---- Got EOF on data connection
> ---- Closing data socket
> 1719784995 bytes transferred in 9 seconds (181.65M/s)
> 
> Same file (via CIFS): 50MB/s
> 
> Device eth6 [10.0.1.2] (1/1):
> ================================================================================
> Incoming:                               Outgoing:
> Curr: 49.17 MByte/s                     Curr: 0.58 MByte/s
> Avg: 8.76 MByte/s                       Avg: 0.03 MByte/s
> Min: 0.00 MByte/s                       Min: 0.00 MByte/s
> Max: 197.68 MByte/s                     Max: 0.86 MByte/s
> Ttl: 585.87 GByte                       Ttl: 6.97 GByte
> 
> 0.02user 4.09system 0:33.84elapsed 12%CPU (0avgtext+0avgdata 3632maxresident)k
> 
> The RAID's on both systems can achieve > 750MiB/s sustained without any
> problems (benchmarked in the past) and the system has 56 PCI-e 2.0 lanes
> and a cable between two 10GbE nics.  Not sure where to start, Win7/box tweaks
> or Linux/CIFS options?
> 
> Again, Samba -> Linux = 500MiB/s, so FTP > 3x faster than CIFS.
> I know NFS gets a lot of testing (never had an issue with it/performance/etc)
> 
> However, regarding CIFS-- is there a test suite/or benchmark pack the CIFS 
> developers use to make sure everything is working in order?
> 
> Justin.
> 
> 

Like I said, read performance with cifs.ko just plain sucks currently.

Don't look for cifs.ko to achieve anywhere near NFS' performance unless
you jump through some very odd hoops (like multithreading your workload
in userspace, etc). cifs.ko just doesn't do a good job of keeping the
pipe "stuffed" as most calls are handled synchronously. A single task
can only handle one call on the wire in most cases. The exception here
is writes, but that just recently changed...

Reads are done using relatively small buffers and then copied to
pagecache. Part of what I'm working on will be to allow for much larger
reads directly into the pagecache. That should also help performance
significantly.

-- 
Jeff Layton <jlayton@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/