DBus and epoll

[Alban Crequy]

Le Mon, 25 Oct 2010 12:29:41 +0200,
<anttu.t.koski at nokia.com> a écrit :

> In my testing with around 350 file descriptors it seems that almost
> 3/4 of the time in DBus functions is spent in polling. If I run the
> test when there is only a couple of fds present, the latencies drop
> by about 50%. I guess that when there are thousands of descriptors,
> the latencies are already huge. Epoll should scale much better.

I don't know if it is exactly your issue here but there was a
performance problem in the Linux kernel with select/poll on Unix
sockets causing a process (in your case dbus-daemon) running poll() or
select() to wake up unnecessarily when processes on the other end of
the socket (in your case, dbus peers) perform a read(). The
unnecessary wakes-up happened in kernel side, they used a bit of CPU
and they were not visible with strace.

3 patches were applied to the linux-next branch, but it is not in any
stable Linux release. See thread:
http://www.spinics.net/lists/netdev/msg145533.html

For future reference:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=67426b756c4d52c511c4b22b269accea171692a8
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=5456f09aaf88731e16dbcea7522cb330b6846415
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=973a34aa8593dbfe84386343c694f5beecb51d8a

Alban