On Thu, Jul 10, 2008 at 09:33:43PM +0200, Valery Kholodkov wrote: > > William Ahern wrote: > >On Thu, Jul 10, 2008 at 02:20:33PM +0200, Valery Kholodkov wrote: > ><snip> > >>As an example I have implemented asynchronous gzipper (see aio-test.c). > >>However I found, that this example does not outperform gzip, since > >>benefits of AIO appear themselfs only in specific conditions. One has to > >>deal with multiple buffers to get better performance, which is outside of > >>the scope of the example. > > > >I wouldn't expect AIO to knock your socks off on Linux (and certainly not > >*BSDs). Kernel support doesn't exist for AIO operating through the disk > >buffer cache. > > On my system (FreeBSD 7.0) I supposed to say "kldload aio" for this > patch to work. What kind of AIO support it is, if it is not a kernel?
There are many ways to do AIO. I know of none that don't use threads, either kernel threads or user process threads. Now, the threads could be "light weight", but there's still a calling context that blocks on an operation. But no implementation is equivalent to, say, how the socket subsystem [state machines] work, where the only state that needs to be maintained is a queue of waiting objects (where object != thread). To put it simply, all the AIO implementations use too much memory and do too much book keeping (like thread scheduling) than strictly necessary, because kernels don't have a way to to "poll" on VM pages (as opposed to polling on disk interrupts, which you can accomplish when do doing direct I/O). It sounds academic, and it mostly is, unless/until you expect your socks to be blown off my AIO performance. For instance, this why AIO is not the fastest I/O backend on lighttpd, for instance (though, it's probably the sanest). <snip> > As I understand vmsplice() will never support nonblocking operations on > files, since vmsplice() requires fd to refer to a pipe, otherwise it > returns EBADF. Oops. Right. splice(), I mean. splicing from a regular file to a pipe (but to get that data in process memory you than have to vmsplice from that pipe). But in any event, splice() can block on the regular file I/O, no matter whether you specified O_NONBLOCK or not. And Linus has rejected even simple hacks to prevent the blocking; his argument is, of course, that since there's no way to poll for readiness it's pointless to not block. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
