public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David E. Weekly" <dweekly@legato.com>
To: "ML-linux-kernel" <linux-kernel@vger.kernel.org>
Subject: Efficient Event Handling In Linux?
Date: Wed, 8 Aug 2001 16:24:51 -0700	[thread overview]
Message-ID: <00a201c12061$52dc7260$5c044589@legato.com> (raw)

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



             reply	other threads:[~2001-08-08 23:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-08 23:24 David E. Weekly [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-08-11  3:11 Efficient Event Handling In Linux? Dan Kegel
2001-08-13  8:43 ` jury gerold

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='00a201c12061$52dc7260$5c044589@legato.com' \
    --to=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