Performance limitation in read(1)

[David Collier-Brown -- Customer Engineering]

   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...

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