Performance limitation in read(1)
Richard Sharpe
rsharpe at richardsharpe.com
Mon Aug 11 16:38:58 GMT 2003
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
More information about the samba-technical
mailing list