| |||||||||||||
Kernel events without kernel callsKernel events without kernel callsPosted Mar 15, 2007 14:03 UTC (Thu) by pphaneuf (guest, #23480)In reply to: Kernel events without kernel calls by corbet Parent article: Kernel events without kevents
And, as per that linked article, when events are consumed from the ring buffer, kevent_commit() (which I presume is a system call, "calling into the kernel"), has to be called "from time to time". Some batching can be done, but this is very similar to the kind of batching that happens when calling epoll_wait() with a "maxevents" parameter bigger than one. So, there's a system call at a similar frequency as epoll occuring. I'll grant you, there is some opportunity for less copying of the events structures, as I mentioned, but that's it.
(Log in to post comments)
Kernel events without kernel calls Posted Mar 22, 2007 22:56 UTC (Thu) by hno (guest, #43549) [Link] There is significant difference between epoll and ring buffer batching.
with epoll you have an syscall each and every time you want to process events, even if there is a single event to process.
With a ring buffer you only need to notify the kernel when there is a risk the kernel may run out of space in the buffer. For example once per rinbuffersize/2 number of events processed.
But it's true that when you get heavily CPU bound and not able to keep up with the rate of events the two converges to about the same. But as long as processing is able to keep up with the rate of events the ring buffer always wins, i.e. in all situations except complete overload.
So in worst case the ring buffer performs equal to explicit call, on average significantly better than explicit call.
|
|||||||||||||