Posted Aug 3, 2006 12:30 UTC (Thu) by pphaneuf
Parent article: Toward a kernel events interface
Maybe I just haven't done high enough bandwidth applications, but a system call to get the events from the kernel isn't exactly murder. Hopefully, you do a lot of work in-between the calls to the event dispatching system call.
The problem isn't the system call, really, but the copying of the events from the kernel buffers to the user buffers. In fact, when it is said that the kevent_get_events() call could go away and be replaced by a simple "wait for events" interface, what would be that "interface", if not a system call itself? User processes going to sleep basically have to include a system call! You could only take the system call out in the overload case, where you'd basically run circles in the ring buffer as fast as you could (which can be an interesting feature). How would one indicate to the kernel where it is at in the ring buffer, and how would the userspace code know where the end is (and whether it has to go to sleep or not)? I am not familiar with the interfaces of
Is there such a volume of events themselves that copying them to userspace is significant?
Something I would like to have and which would reduce the system call overhead would be a way of specifying for a specific file descriptor that it should not be marked readable until there is a certain amount of data. Or that it should not be marked writable until there is space for at least a certain amount of available space. This should of course be overridden if there is an error on the file descriptor (say, EOF would mark an fd as readable). This would allow applications that use a certain block size to read whole blocks at a time (with a single read() syscall).
to post comments)