Skip site navigation (1)Skip section navigation (2)
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+FcrnrGsr5gG2Za_=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: <http://docs.FreeBSD.org/cgi/mid.cgi?CABXB=RQWxu-d30raZ+FcrnrGsr5gG2Za_=cx8-jCnLSgJDSF=Q>