From: jury gerold <geroldj@grips.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "David E. Weekly" <dweekly@legato.com>
Subject: Re: Efficient Event Handling In Linux?
Date: Mon, 13 Aug 2001 10:43:40 +0200 [thread overview]
Message-ID: <3B77933C.5080109@grips.com> (raw)
In-Reply-To: <3B74A274.FB34AF2C@kegel.com>
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
>
next prev parent reply other threads:[~2001-08-13 8:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-11 3:11 Efficient Event Handling In Linux? Dan Kegel
2001-08-13 8:43 ` jury gerold [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-08-08 23:24 David E. Weekly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B77933C.5080109@grips.com \
--to=geroldj@grips.com \
--cc=dweekly@legato.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.