[linux-cifs-client] Re: suggestion required

[Steve French]

The general idea of forking i/o threads for cifs readahead is probably 
ok but there may be easier ways.  For writebehind it makes more sense.

Note that currently there are two types of background threads that cifs 
has - an oplock thread for receiving/processing asynchronous oplock 
breaks (ie releasing distributed caching tokens) and one cifsd thread 
per tcp socket (unique connection to a server) for demultiplexing responses.

A couple of ideas worth evaluating are:
1) creating one or more writebehind threads to manage the asynchronous 
completion on these events.  In this design cifs_writepages would simply 
put dirty pages on a list and return (unless the inode is marked as 
requiring synchronous writes) that would be dispatched by the background 
thread.
2) creating a cifs_readpages implementation that dispatches more than 
one SMB read request at a time (basically does writes to the tcp socket 
of a series of read requests, one immediately after another - but this 
complicates the completion logic)

We obviously want to reduce CPU usage on the client (by removing the 
extra memcpy in the CIFSSMBWrite path as well as the extra memcpy in the 
CIFSSMBRead path) not just maximizing parallelism (which can do more 
harm than good if we don't throttle back the number of simultaneous 
read/write requests to the server intelligently - I noticed that the 
Linux NFS client seems to dispatch typically 3 to 4 reads in parallel - 
although relatively small reads by default which probably hurts their 
performance).   In addition we want to use the maximum size reads and 
writes possible (at least 127K is possible now) to minimize the number 
of interrupts the server has to process and maximize network 
efficiency.    Once we get past that - some really exciting 
possibilities open up when we can start using newer transport protocols 
such as the SCTP standard (which is found in some of the high end 
adapters already, and also in Linux kernel) or other higher performance 
transports that offload more of the network protocol handling (and do 
their own framing - making more parallelism on the client a bit easier).

Lots of chances for interesting coding or performance analysis projects.

Feel free to ask questions - and of course patches, suggestions and bug 
fixes are welcome.