Date: Sun, 9 Nov 2014 14:57:05 -0500 From: J David <j.david.lists@gmail.com> To: freebsd-hackers@freebsd.org, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: How thread-friendly is kevent? Message-ID: <CABXB=RQWxu-d30raZ%2BFcrnrGsr5gG2Za_=cx8-jCnLSgJDSF=Q@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RQWxu-d30raZ%2BFcrnrGsr5gG2Za_=cx8-jCnLSgJDSF=Q>