Messages in this thread | | | Date | Fri, 28 Jul 2006 22:44:45 +0400 | From | Evgeniy Polyakov <> | Subject | Re: [RFC 1/4] kevent: core files. |
| |
On Fri, Jul 28, 2006 at 11:33:16AM -0700, Zach Brown (zach.brown@oracle.com) wrote: > > > I completely agree that existing kevent interface is not the best, so > > I'm opened for any suggestions. > > Should kevent creation/removing/modification be separated too? > > Yeah, I think so.
So, I'm going to create kevent_create/destroy/control and kevent_get_events() Or any better names?
> >>> Hmm, it looks like I'm lost here... > >> Yeah, it seems my description might not have sunk in :). We're giving > >> userspace a way to collect events without performing a system call. > > > > And why do we want this? > > So that event collection can be very efficient. > > > How glibc is supposed to determine, that some events already fired and > > such requests will return immediately, or for example how timer events > > will be managed? > > ... > > That was what my previous mail was all about!
Some events are impossible to create in userspace (like timer notification, which requires timer start and check when timer completed). Actually all events are part of the kernel, since glibc does not have any knowledge about in-kernel state machines which are bound to appropriate kevents, so each kevent takes at least two syscall (create and get ready), and I do not see how, for exmple, glibc can avoid them when user requested POLLIN or similar event for network dataflow?
According to syscall speed on Linux, last time I checked empty syscall took about 100ns on AMD Athlon 3500+.
> - z
-- Evgeniy Polyakov - 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/
| |