From: Dan Kegel <dank@kegel.com>
To: Aaron Sethman <androsyn@ratbox.org>
Cc: Kev <klmitch@MIT.EDU>, Arjen Wolfs <arjen@euro.net>,
coder-com@undernet.org, feedback@distributopia.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork performance
Date: Sun, 03 Feb 2002 17:16:02 -0800 [thread overview]
Message-ID: <3C5DE0D2.77DDE891@kegel.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0202031955480.3086-100000@simon.ratbox.org>
Aaron Sethman wrote:
>
> On Sun, 3 Feb 2002, Dan Kegel wrote:
>
> > Kev wrote:
> > >
> > > > The /dev/epoll patch is good, but the interface is different enough
> > > > from /dev/poll that ircd would need a new engine_epoll.c anyway.
> > > > (It would look like a cross between engine_devpoll.c and engine_rtsig.c,
> > > > as it would need to be notified by os_linux.c of any EWOULDBLOCK return values.
> > > > Both rtsigs and /dev/epoll only provide 'I just became ready' notification,
> > > > but no 'I'm not ready anymore' notification.)
> > >
> > > I don't understand what it is you're saying here. The ircu server uses
> > > non-blocking sockets, and has since long before EfNet and Undernet branched,
> > > so it already handles EWOULDBLOCK or EAGAIN intelligently, as far as I know.
> >
> > Right. poll() and Solaris /dev/poll are programmer-friendly; they give
> > you the current readiness status for each socket. ircu handles them fine.
>
> I would have to agree with this comment. Hybrid-ircd deals with poll()
> and /dev/poll just fine. We have attempted to make it use rtsig, but it
> just doesn't seem to agree with the i/o model we are using...
I'd like to know how it disagrees.
I believe rtsig requires you to tweak your I/O code in three ways:
1. you need to pick a realtime signal number to use for an event queue
2. you need to wrap your read()/write() calls on the socket with code
that notices EWOULDBLOCK
3. you need to fall back to poll() on signal queue overflow.
For what it's worth, my Poller library takes care of fallback to poll
transparantly, and makes the EWOULDBLOCK stuff fairly easy. I gather
from the way you quoted my previous messsage, though, that you
consider rtsig too awful to even think about.
> I haven't played with /dev/epoll yet, but I pray it is nothing like rtsig.
Unfortunately, it is exactly like rtsig in how you need to handle
EWOULDBLOCK.
> Basically what we need is, something like poll() but not so nasty.
> /dev/poll is okay, but its a hack. The best thing I've seen so far, but
> it too seems to take the idea so far is FreeBSD's kqueue stuff(which
> Hybrid-ircd handles quite nicely).
Yes, kqueue is quite easy to use, and doesn't require the gyrations
that rtsig or /dev/epoll require. The only thing that makes rtsig or /dev/epoll
usable are user-space wrapper libraries that let you forget about the
gyrations (mostly).
- Dan
next prev parent reply other threads:[~2002-02-04 1:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-29 18:00 PROBLEM: high system usage / poor SMP network performance Dan Kegel
2002-01-29 20:09 ` Vincent Sweeney
2002-01-31 5:24 ` Dan Kegel
[not found] ` <001d01c1aa8e$2e067e60$0201010a@frodo>
2002-02-03 8:03 ` Dan Kegel
2002-02-03 8:36 ` Andrew Morton
2002-02-04 14:57 ` [Coder-Com] " Darren Smith
2002-02-04 17:41 ` Aaron Sethman
2002-02-04 18:11 ` Darren Smith
2002-02-04 18:30 ` Aaron Sethman
2002-02-04 18:48 ` Kev
2002-02-04 18:59 ` Aaron Sethman
2002-02-04 18:53 ` Doug McNaught
2002-02-08 22:11 ` James Antill
2002-02-12 18:48 ` Vincent Sweeney
2002-02-03 19:22 ` Kev
[not found] ` <5.1.0.14.2.20020203173247.02c946e8@pop.euronet.nl>
2002-02-03 19:16 ` [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork performance Dan Kegel
2002-02-04 0:07 ` Kev
2002-02-04 0:37 ` Dan Kegel
2002-02-04 0:59 ` Aaron Sethman
2002-02-04 1:16 ` Dan Kegel [this message]
2002-02-04 1:30 ` Aaron Sethman
2002-02-04 1:38 ` Dan Kegel
2002-02-04 4:38 ` Aaron Sethman
2002-02-04 5:35 ` Dan Kegel
2002-02-04 5:43 ` Aaron Sethman
2002-02-04 6:11 ` Daniel Phillips
2002-02-04 6:26 ` Aaron Sethman
2002-02-04 6:29 ` Daniel Phillips
2002-02-04 6:39 ` Aaron Sethman
2002-02-04 2:55 ` Kev
2002-02-04 3:25 ` Dan Kegel
2002-02-04 4:47 ` Aaron Sethman
2002-02-04 5:10 ` Kev
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=3C5DE0D2.77DDE891@kegel.com \
--to=dank@kegel.com \
--cc=androsyn@ratbox.org \
--cc=arjen@euro.net \
--cc=coder-com@undernet.org \
--cc=feedback@distributopia.com \
--cc=klmitch@MIT.EDU \
--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