On Sat, 12 Jul 2003, Eric Varsanyi wrote:
> > > The problem with all the level triggered schemes (poll, select, epoll w/o
> > > EPOLLET) is that they call every driver and poll status for every call into
> > > the kernel. This appeared to be killing my app's performance and I verified
> > > by writing some simple micro benchmarks.
> >
> > Look this is false for epoll. Given N fds inside the set and M hot/ready
> > fds, epoll scale O(M) and not O(N) (like poll/select). There's a huge
> > difference, expecially with real loads.
>
> Apologies, I did not benchmark epoll level triggered, just select.
> The man page claimed epoll in level triggered mode was just a better
> interface so I assumed it had to call each driver to check status.
It is not neither better nor worse. For sure it is more close to what
existing apps do, and it is easier to understand.
> Reading thru it I see (I think) the clever trick of just repolling things
> that have already triggered (basically polling just for the trailing
> edge after having seen a leading edge async), cool!
>
> If it seems unpopular/unwise to add the extra poll event to show read EOF
> using this level triggered mode would likely do the job for my app (the
> extra polls every time for un-consumed events will be nothing compared to
> calling every fd's poll every time).
Even if it is true that you can drop an extra read(), having the RDHUP
event will cost exactly zero extra CPU cycles inside the kernel, and one
changed line of code (plus arch definitions in asm/poll.h). To me, it
looks acceptable. Let's see what DaveM think about it.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:45 EST