2.5 readpages doubles cifs vfs large file copy performance vs.
David Collier-Brown -- Customer Engineering
David.Collier-Brown at Sun.COM
Fri Jul 4 12:58:50 GMT 2003
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
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.
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
More information about the samba-technical