Messages in this thread | | | Date | Tue, 19 Nov 2002 12:54:47 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [rfc] epoll interface change and glibc bits ... |
| |
On Tue, 19 Nov 2002, Mark Mielke wrote:
> On Tue, Nov 19, 2002 at 11:51:40AM -0800, Davide Libenzi wrote: > > On Tue, 19 Nov 2002, Grant Taylor wrote: > > > If we're bound to poll small sets of epoll fds perhaps a bit of > > > improvement in poll would be worthwhile. I should go look at my > > The current poll() with a number of fds you're talking about, scales > > beautifully. > > For event loops that need minimal latency for high priority events > (even at the cost of higher latency for low priority events), poll() > of epoll fds may allow greater optimization opportunities, as the > epoll fd set is dynamically adjusted without extra system code > overhead. > > Example: Code that expects that at least one high priority event may > be ready (for example, after dispatching events during the previous > iteration) can choose to first only poll(0) the epoll fds responsible > for the high priority event sets. Only if poll(0) returns no high > priority epoll fds, would poll(timeout) then be issued on all epoll > fds. This would result in a very short dispatch path for events for > high priority events. > > What we really need is a few actual event loop implementations to test > all of these theories. I would find it especially nice if the code > could be ported to 2.4.x... :-)
I think it's better to wait to define the final interface ( and eventpoll code bits ) before starting the 2.4.x backport patch.
- 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/
| |