2.5 readpages doubles cifs vfs large file copy performance vs. 2.4

[David Collier-Brown -- Customer Engineering]

Steven French wrote:
>> I forgot to mention something obvious - eventually the read ahead 
>> logic of linux itself could kick in (see mm/readpages.c) and for this 
>> case that behavior is important to understand as well as how the 
>> filesystem is formatted and the properties of the underlying block 
>> device.  

	And that would be a Really Good Thing, and comments from
	jeremy indicate that this may be happening. He noted that
	the read cache buffer setting was predominantly useful
	on Solaris, not Linux.  I suspect the same may be true
	of read caching: I'll test that today on ext3/IDE, and
	see about doing a comparative test on ext3/scsi and
	ufs/scsi with two arguably comparable Intel and Sun
	boxes (same scsi drives, same clock speed, different
	everything else) at home.

>>       In any case - the client read size may have less effect on the 
>> disk performance than the common Linux readahead algorithm in 
>> mm/readahead.c but the client read size makes a huge difference in 
>> single client cases unconstrained disk cases since it more efficiently 
>> uses the network bandwidth and minimizes server dead time when nothing 
>> is going on due to client processing delay.

	Hmmn, I wonder... postulate the the client tasks for 1, 16 and
	64 KB. Linux readahead will definitely fire on the 16k read,
	and might on the 1k read, allowing reads of a size based on
	the size wanted by the memory management subsystem. If this is
	large enough to fall into the "sweet spot", then even the 	
	single-reader case will proceed fairly rapidly.

--dave
-- 
David Collier-Brown,           | Always do right. This will gratify
Sun Microsystems DCMO          | some people and astonish the rest.
Toronto, Ontario               |
(905) 415-2849 or x52849       | davecb at canada.sun.com