Solved (sort of): Strange VFS performance problem

David Collier-Brown David.Collier-Brown at Sun.COM
Thu Feb 17 20:51:37 GMT 2005

Terry Griffin wrote:

> The final culprit was AIO, or rather the absence of any mechanism
> for a user-space application to "instantly" respond to the completion
> of an AIO operation. The 4K sizes sent to VFS pwrite() via the
> Linux/CIFS client made things worse but was not the root cause.
> The original sequence in my VFS modules's pwrite() was:
> - aio_write()
> - Do some other useful stuff with the data
> - Polling loop: aio_error()/nanosleep()
> - aio_return()
> The problem is nanosleep(). (See the BUGS section of the man page.)
> It sleeps way too long for this to be efficient when the data is
> coming in over 1Gb Ethernet.
> One workaround is:
> - aio_write()
> - Do some other useful stuff with the data
> - nice(1)
> - Polling loop: aio_error(), but no sleeping!
> - nice(-1)
> - aio_return()
> This gives me a ten-fold improvement in throughput with the
> Linux/CIFS 4K-writes. The nice(1)/nice(-1) thing is required so the
> polling loop doesn't take CPU away from the aio_write() operation.
> What I really need is a blocking aio_error() with instant return
> on completion of the AIO operation. A real nanosleep() might also
> do it.

	Look and see how the academic lisp community implement
	"futures", which is a mechanism to express exactly what
	you describe...

	(set fx  (future(some fucntion call)))
	(do something else)
	(set y (future x))

	Google pointed me at

> Terry

David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at     |                      -- Mark Twain

More information about the samba-technical mailing list