poll vs. epoll
dank at kegel.com
Tue Aug 24 23:51:01 CDT 2004
Shachar Shemesh wrote:
>> Now don't go and do level-triggered stuff just because it's easier :-)
> That's not it at all, and edge vs. level is not part of my
> considerations. Libevent does support a wider variety of selection
> interfaces, and with wider platform support, than your library.
Don't get me wrong. Libevent is good stuff. Niels is a very good guy.
I don't think platform support is an issue (which platform do you need?)
The one interface rn is missing, I think, is a timer.
Buffered events would be a fine addition, too.
But rn has the basic notification stuff; it was intended to focus on those.
>> I don't think it's fair to say level-triggered is ideal for
>> wineserver. In fact, wineserver is an example of the kind
>> of program that is easier to convert to edge-triggering
>> than most programs, since it's small and self-contained.
> Can you give benchmarks for performance differences between the two?
The essential difference is that level-triggered means more notifications
coming from kernel space, which always means higher overhead. The difference
is going to be slight.
I have also noticed that in some situations where the interest mask
is hard to compute, using edge triggered is much easier, because you
never have to compute it.
> The more I think about it, the more I'm getting the impression that going
> edge trigger means we need to maintain our own cache of not-yet-useful
The same cache is maintained in the kernel for you if you use level triggering.
> as well as risking starvation.
There is no risk of starvation in a properly written program.
> Also, can you show me how to do edge trigger via poll?
There is no need for that, since Linux and *BSD all support some
form of edge-triggered notification. However, if we want to
support ancient operating systems, it wouldn't be too hard to
add poll() support to rn under the covers, and present the edge-triggered
interface to the user.
> I'll qualify the starvation claim.
> Suppose we have five fds we are watching. Suppose one (let's call it
> "3") of them is really really intensive in it's request rate. Using the
> current interface (as used in the preliminary patch I sent), each time
> we call epoll we will see that 3 is active, but any time any other fd
> has anything to do, it will be handled.
> Suppose we go edge triggered now. We call epoll, and it's likely that 3
> will be the only one active. We will call the 3 handling function, which
> will try to exhaust the requests arriving on 3 before returning. No it's
> a problem - requests potentially are never exhausted on 3. When do we
> exit the handler to do other stuff? We would need to write some
> mechanism to introduce this fairness ourselves.
Yes, but that's easy. It's about four lines of code.
> In short, if you are going edge trigger, your relative scheduling
> priority is your responsibility, as well as keeping all partial memory
> buffered. With level trigger, the kernel does that for you.
What's this about partial memory buffering? Sounds like you're inventing
a difficulty here.
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
More information about the wine-devel