Performance limitation in read(1)

[Richard Sharpe]

On Mon, 11 Aug 2003, David Collier-Brown -- Customer Engineering wrote:

>    One of my senior colleagues was looking at samba performance,
> looking for opportunities to speed it up from the Solaris side,
> and noticed that the I/O usage pattern was, well, sort horrible...

Well, there is a 33-byte plus header on the front, and the overhead for 
the Read&X contains an even number of bytes, so the whole header is 
odd-length.

In anycase, it is much more efficient to avoid the copy altogether and 
use sendfile and recvfile.
 
> James Litchfield wrote:
> > In the process of tracking down why some changes [...]
> > weren't producing any benefit, it was noted that almost 
>  > every IO that Samba did was to a buffer in user land with
>  > an odd byte address:
> > 
> > 1262:   read(12, 0x00233FA5, 52)                        = 52
> > 1262:   read(12, 0x00233FA1, 4)                         = 4
> > 1262:   read(12, 0x00233FA5, 42)                        = 42
> > 1262:   read(12, 0x00233FA1, 4)                         = 4
> > 1262:   read(12, 0x00233FA5, 99)                        = 99
> > 1262:   read(12, 0x00233FA1, 4)                         = 4
> > 
> > Inquiring minds want to know: why? [...snip] 
>  >                                           Maximum benefit
>  > for large copies (> 512 bytes on US-II systems) today and
>  > in the future would be to a 64-byte aligned buffer.
> 
> 	I have a proposed read cache buffer in the queue,
> 	which will result in performance advanatage **if
> 	and only if it's used**, but would we not be
> 	well-advised to start with a cache which is
> 	a multiple of the block size, and could be aligned
> 	nicely on systems which benefit from that?
> 
> --dave
> 

-- 
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com