Re: Efficient Event Handling In Linux?

Re: Efficient Event Handling In Linux?

[Dan Kegel]

"David E. Weekly" <dweekly@legato.com> wrote:
> Hey all. I've been looking at efficient event-handling mechanisms (for I/O
> on sockets, disk, devices) ... As far as I could tell ... the discussion 
> [on linux-kernel] trailed off without any real resolution as to what
> would actually be done to empower Linux with efficient event handling;
> perhaps I missed it, but I couldn't find Linus's get_events/bind_event
> calls, nor could I find /dev/poll or kqueue-styled interfaces integrated
> into the latest kernel.
> I did find what looks to be an excellent patch in the way of /dev/epoll
> (written up here:
> http://www.xmailserver.org/linux-patches/nio-improve.html). According to the
> benchmarks he's got, the patch really spanks /dev/poll and POSIX SIGIO. I'm
> going to begin testing with it soon and was hoping to get some feel for
> whether /dev/epoll might end up in the kernel mainstream at some point in
> the not-too-distant future? 

My impression is that /dev/epoll is the best for sockets at the moment, and 
that several people are using it happily now.  (The interface is
still in flux, I think, so only use it now if you don't mind that.)

However, for disk I/O, IMHO you really want aio instead.
If you need aio now, SGI's kaio patch is available and is said to work well 
(and heck, there's also a userland emulation in glibc, but I 
suspect it doesn't perform well).
For the future, Ben LaHaise's aio may have better performance when it's done
( http://uwsg.iu.edu/hypermail/linux/kernel/0102.0/0459.html );
he's going to do things like async sendfile, and is willing to provide a nonposix
interface for those who don't want signal delivery's overhead
(see http://uwsg.iu.edu/hypermail/linux/kernel/0102.0/0384.html
and http://www.kvack.org/~blah/aio/v2.4.5-ac9-bcrl4-aio.diff )

I suspect both /dev/epoll and LaHaise's aio will end up being integrated 
into the stock 2.5 kernel.  And if we're really lucky, there will be 
a single integrated event stream for both.  I'm quite annoyed
that Posix defines separate polling methods for file descriptors
and aio completions (http://www.opengroup.org/onlinepubs/7908799/xsh/aio_suspend.html);
if one simple interface can handle both, we ought to try to do it.

- Dan "but I play one on TV" Kegel

-- 
"Computers are state machines.
 Threads are for people who can't program state machines."  - Alan Cox

Re: Efficient Event Handling In Linux?

[jury gerold]

I want to add, that the SGI kaio patch handles disk as well as sockets.

Gerold

Dan Kegel wrote:

>"David E. Weekly" <dweekly@legato.com> wrote:
>
>>Hey all. I've been looking at efficient event-handling mechanisms (for I/O
>>on sockets, disk, devices) ... As far as I could tell ... the discussion 
>>[on linux-kernel] trailed off without any real resolution as to what
>>would actually be done to empower Linux with efficient event handling;
>>perhaps I missed it, but I couldn't find Linus's get_events/bind_event
>>calls, nor could I find /dev/poll or kqueue-styled interfaces integrated
>>into the latest kernel.
>>I did find what looks to be an excellent patch in the way of /dev/epoll
>>(written up here:
>>http://www.xmailserver.org/linux-patches/nio-improve.html). According to the
>>benchmarks he's got, the patch really spanks /dev/poll and POSIX SIGIO. I'm
>>going to begin testing with it soon and was hoping to get some feel for
>>whether /dev/epoll might end up in the kernel mainstream at some point in
>>the not-too-distant future? 
>>
>
>My impression is that /dev/epoll is the best for sockets at the moment, and 
>that several people are using it happily now.  (The interface is
>still in flux, I think, so only use it now if you don't mind that.)
>
>However, for disk I/O, IMHO you really want aio instead.
>If you need aio now, SGI's kaio patch is available and is said to work well 
>(and heck, there's also a userland emulation in glibc, but I 
>suspect it doesn't perform well).
>For the future, Ben LaHaise's aio may have better performance when it's done
>( http://uwsg.iu.edu/hypermail/linux/kernel/0102.0/0459.html );
>he's going to do things like async sendfile, and is willing to provide a nonposix
>interface for those who don't want signal delivery's overhead
>(see http://uwsg.iu.edu/hypermail/linux/kernel/0102.0/0384.html
>and http://www.kvack.org/~blah/aio/v2.4.5-ac9-bcrl4-aio.diff )
>
>I suspect both /dev/epoll and LaHaise's aio will end up being integrated 
>into the stock 2.5 kernel.  And if we're really lucky, there will be 
>a single integrated event stream for both.  I'm quite annoyed
>that Posix defines separate polling methods for file descriptors
>and aio completions (http://www.opengroup.org/onlinepubs/7908799/xsh/aio_suspend.html);
>if one simple interface can handle both, we ought to try to do it.
>
>- Dan "but I play one on TV" Kegel
>

Efficient Event Handling In Linux?

[David E. Weekly]

Hey all. I've been looking at efficient event-handling mechanisms (for I/O
on sockets, disk, devices) on various operating systems; poking through the
list archives reveals some excellent, juicy discussions that flared up
around late October, with Linus strongly in favor of a new
"get_events/bind_event()" style, some parties in favor of a FreeBSD kqueue
style, and some fans of Solaris 8's /dev/poll flavor.

As far as I could tell (and my most humble of apologies if this is not the
case), the discussion trailed off without any real resolution as to what
would actually be done to empower Linux with efficient event handling;
perhaps I missed it, but I couldn't find Linus's get_events/bind_event
calls, nor could I find /dev/poll or kqueue-styled interfaces integrated
into the latest kernel.

I did find what looks to be an excellent patch in the way of /dev/epoll
(written up here:
http://www.xmailserver.org/linux-patches/nio-improve.html). According to the
benchmarks he's got, the patch really spanks /dev/poll and POSIX SIGIO. I'm
going to begin testing with it soon and was hoping to get some feel for
whether /dev/epoll might end up in the kernel mainstream at some point in
the not-too-distant future? If not, what? It seems a shame for Linux to be
somewhat behind Solaris (/dev/poll), FreeBSD (kqueue), and Windows2000
(Completion Ports) in performance; it would be fabulous to see formal
acceptance of /dev/epoll or something equivalent.

Is Linux really not that far behind performance-wise (i.e., most of these
benchmarks are misleading)? Have there already been good performance patches
in this style? Please fill me in, though I've got a feeling I'm not the only
one a little clueless on what the current state of affairs is in this
department. =)


 -david


[reference: Linus's suggestion for get_events/bind_event()]
http://uwsg.iu.edu/hypermail/linux/kernel/0010.3/0003.html