From: "Christopher K. St. John" <cks@distributopia.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Davide Libenzi <davidel@xmailserver.org>
Subject: Re: /dev/yapoll : Re: [PATCH] /dev/epoll update ...
Date: Fri, 21 Sep 2001 15:21:46 -0500 [thread overview]
Message-ID: <3BABA15A.57255E63@distributopia.com> (raw)
In-Reply-To: <XFMail.20010921131017.davidel@xmailserver.org>
Davide Libenzi wrote:
>
> By reporting the initial state of the connection will
> make /dev/epoll to be a hybrid interface
>
Yes, but you need that anyway (see below)
> and looks pretty crappy to me.
>
Talk to the people who wrote the paper (and won
"Outstanding Paper" for it at Usenix). The paper
is quite convincing, so I'm afraid I'll have to
disagree. But as I said, I'll know more when I've
tested further.
It turns out that a hybrid interface is needed
in any case to handle overload. When the queues
start to fill up, you need to back off and start
basically doing something like a plain-old-poll()
instead. Ref the paper. Here's a link to a kernel
list dicussion that covers similiar ground:
http://kt.linuxcare.com/kernel-traffic/kt20001113_93.epl
Also, merging events for the same fd, which
everyone seems to agree is a good thing, is
in fact a "hybrid" approach, right? Since
you're now tracking state (albeit only between
calls to ioctl(EP_POLL).
I intend to use some of the original Linux
/dev/poll code, as well as some of yours, but
it's a new patch with a new name.
--
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com
next prev parent reply other threads:[~2001-09-21 20:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-21 6:22 [PATCH] /dev/epoll update Dan Kegel
2001-09-21 18:45 ` Davide Libenzi
2001-09-21 19:40 ` /dev/yapoll : " Christopher K. St. John
2001-09-21 20:10 ` Davide Libenzi
2001-09-21 20:21 ` Christopher K. St. John [this message]
2001-09-21 21:36 ` Davide Libenzi
2001-09-21 21:33 ` Christopher K. St. John
2001-09-21 21:52 ` Davide Libenzi
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=3BABA15A.57255E63@distributopia.com \
--to=cks@distributopia.com \
--cc=davidel@xmailserver.org \
--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.