Recent Features
| |||||||||||||
Performance aspectsPerformance aspectsPosted Aug 3, 2006 12:30 UTC (Thu) by pphaneuf (guest, #23480)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).
(Log in to post comments)
Performance aspects Posted Aug 3, 2006 15:44 UTC (Thu) by kleptog (subscriber, #1183) [Link] The thing is, there already are a whole lot of features to deal with this, many of which are not used as often as they should.
For example, the "minimum amount of data" option exists already for ages for socket (SO_LOWWAT or some such). There's POSIX realtime signals which can be queued and even start a new thread at a particular callback when the signal arrives.
All these things are aimed at the really high end though, 99% of programs don't need to worry about this much...
Performance aspects Posted Aug 3, 2006 16:20 UTC (Thu) by pphaneuf (guest, #23480) [Link] According to socket(7), there's SO_RCVLOWAT and SO_SNDLOWAT, but they are not changeable on Linux, being always set at 1 (i.e. nothing special). Waiting for POSIX signals is a system call too (in fact, getting them too). I don't think there's anything about starting new threads like that on Linux. Performance-wise, other than holding off readiness events until a certain amount is ready (which appears already has an unimplemented API), I'm fairly happy. Back when I used epoll in edge-triggered mode, I would have liked a way to batch calls to epoll_ctl(), when I re-armed my events, but now I just let the kernel-side level-triggered mode do the work.
Performance aspects Posted Aug 3, 2006 16:37 UTC (Thu) by cventers (subscriber, #31465) [Link] Realtime signals and new-thread callbacks were mentioned in Ulrich's OLSpaper. He went on to show how truly inoptimal they were.
|
|||||||||||||