* Jeff Garzik <[email protected]> wrote:
> >>You should pick up the kevent work :)
> >
> >3 months ago i verified the published kevent vs. epoll benchmark and
> >found that benchmark to be fatally flawed. When i redid it properly
> >kevent showed no significant advantage over epoll. Note that i did
> >those measurements _before_ the recent round of epoll speedups. So
> >unless someone does believable benchmarks i consider kevent an
> >over-hyped, mis-benchmarked complication to do something that epoll
> >is perfectly capable of doing.
>
> You snipped the key part of my response, so I'll say it again:
>
> Event rings (a) most closely match what is going on in the hardware
> and (b) often closely match what is going on in multi-socket,
> event-driven software application.
event rings are just pure data structures that describe a set of data,
and they have advantages and disadvantages. For the record, we've
already got direct experience with rings as software APIs: they were
used for KAIO and they were an implementational and maintainance
nightmare and nobody used them. Kevent might be better, but you make it
sound as if it was a trivial design choice while it certainly isnt!
Sure, for hardware interfaces like networking cards tx and rx rings are
the best thing but that is apples to oranges: hardware itself is about
_limited_ physical resources, matching a _limited_ data structure like a
ring quite well. But for software APIs, the built-in limit of rings
makes it a baroque data structure that has a fair share disadvantages in
addition to its obvious advantages.
> This is not something epoll is capable of doing, at the present time.
epoll is very much is capable of doing it - but why bother if something
more flexible than a ring can be used and the performance difference is
negligible? (Read my other reply in this thread for further points.)
but, for the record, syslets very much use a completion ring, so i'm not
fundamentally opposed to the idea. I just think it's seriously
over-hyped, just like most other bits of the kevent approach. (Nor do we
have to attach this to syslets and threadlets - kevents are an
orthogonal approach not directly related to asynchronous syscalls -
syslets/threadlets can make use of epoll just as much as they can make
use of kevent APIs.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
