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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox