How thread-friendly is kevent?

J David j.david.lists at gmail.com
Sun Nov 9 19:57:06 UTC 2014


How thread-friendly is kevent()?

In most cases, a dedicated thread does the kevent()-ing and
dispatching work to the thread pool, but at extremely high rates that
thread becomes a significant bottleneck.

As an example, consider a pool of, say, 17 threads on a 16 core
machine all in kevent() waiting for one of 32000 open TCP connections
to be read-ready.  One connection becomes read-ready.  How many
threads will have kevent() return with that event in eventlist?  Is
there potential for a thundering herd problem?

Limited small-scale experimentation suggests that only one thread
returns per event, but it's not documented that way, so it's not clear
if that behavior is intended, an implementation detail, or a
coincidence that won't hold up at scale.

Is this behavior at all guaranteed / by design / intentional?

Although it would be ideal if so, it would also make sense to have to
rely on EV_DISPATCH in multithreaded applications to prevent events
from being delivered more than once, or to use EV_ONESHOT and re-add
the event entirely, depending on which approach better suits the
internal data structure the kernel uses for kqueue.

Thanks for any advice!


More information about the freebsd-hackers mailing list