clisp-devel

non-blocking disk i/o

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

there was a thread here about blocking i/o not working with disks, only with sockets. I remember having read something about this issue somewhere. I seem to remember that only FreeBSD would obey non-blocking i/o for disk files.

All I found now is:
http://www.kegel.com/c10k.html

"An important bottleneck in this method is that read() or sendfile() from disk blocks if the page is not in core at the moment; setting nonblocking mode on a disk file handle has no effect. Same thing goes for memory-mapped disk files."

"Use nonblocking calls (e.g. write() on a socket set to O_NONBLOCK) to start I/O, and readiness notification (e.g. poll() or /dev/poll) to know when it's OK to start the next I/O on that channel. Generally only usable with network I/O, not disk I/O."

"It looks like mincore() is available in BSD-derived Unixes like FreeBSD and Solaris,
but is not part of the Single Unix Specification. It's available as part of Linux as of kernel 2.3.51, thanks to Chuck Lever."

"Use asynchronous calls (e.g. aio_write()) to start I/O, and completion notification (e.g. signals or completion ports) to know when the I/O finishes. Good for both network and disk I/O."

"In 1999, SGI implemented high-speed AIO for Linux. As of version 1.1, it's said to work well with both disk I/O and sockets. It seems to use kernel threads. It is still useful for people who can't wait for Ben's AIO to support sockets."

Regards,
	Jorg Hohle.

non-blocking disk i/o

[<don...@is...>]

Hoehle, Joerg-Cyril writes:
 > Hi,
 > 
 > there was a thread here about blocking i/o not working with disks,
 > only with sockets. I remember having read something about this
 > issue somewhere. I seem to remember that only FreeBSD would obey
 > non-blocking i/o for disk files.

I'm happy to see confirmation of that observation.

 > All I found now is:
 > http://www.kegel.com/c10k.html

Sounds like an asynchronous IO interface would be a good addition to
some future version of clisp.  That would be especially useful for
output, since you know how much you want to send. 

 > "An important bottleneck in this method is that read() or
 > sendfile() from disk blocks if the page is not in core at the
 > moment; setting nonblocking mode on a disk file handle has no
 > effect. Same thing goes for memory-mapped disk files."

This tends to support my theory that the reason it doesn't work is
that paging is not considered to be a case of blocking.

At the moment I'm happy with non-blocking IO to sockets.
That seems to provide (just my impression, no measurement implied)
about 90% of the possible performance for network servers.
If it worked for disk I'd be only about 10% happier.

Asynchronous IO and for that matter multiple threads (I only wish)
actually seem worse to me in the sense that they make scheduling
decisions which the programmer no longer controls, and which he
probably doesn't even understand.  I'd at least like to know how these
are made in order to decide whether I'd rather do it myself.