[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 7 Jul 2015 23:40:17 +0200
From: Johannes Stezenbach <js@...21.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Lukasz Skalski <l.skalski@...sung.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Daniel Mack <daniel@...que.org>,
David Herrmann <dh.herrmann@...il.com>,
Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On Mon, Apr 27, 2015 at 03:14:49PM -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > IOW, all the people who say that it's about avoiding context switches
> > are probably just full of shit. It's not about context switches, it's
> > about bad user-level code.
>
> Just to make sure, I did a system-wide profile (so that you can
> actually see the overhead of context switching better), and that
> didn't change the picture.
>
> The scheduler overhead *might* be 1% or so.
>
> So really. The people who talk about how kdbus improves performance
> are just full of sh*t. Yes, it improves things, but the improvement
> seems to be 100% "incidental", in that it avoids a few trips down the
> user-space problems.
I was interested how plain UDS performs compared to the
dbus-client/dbus-server benchmark when doing a similar
transaction (RPC call from client1 to client2 via a server,
i.e 4 send() and 4 recv() syscalls per RPC msg).
Since I had worked on socket code for some project anyway, I
decided to write a stupid little benchmark.
On my machine, dbus-client/dbus-server needs ~200us per call (1024 byte msg),
UDS "dbus call" needs ~23us. Of course, someone who cares about performance
wouldn't use sync RPC via a message broker, so I added
single-client and async mode to the benchmark for comparison.
Async mode not only decreases scheduling overhead, it also
can use two CPU cores, so it's more than twice as fast.
./server dbus
(you need to run two clients, the timing loop starts
when the second client connects)
./client sync 4096 1000000
22.757250 s, 43942 msg/s, 22.8 us/msg, 171.638 MB/s
./client async 4096 1000000
8.197482 s, 121989 msg/s, 8.2 us/msg, 476.488 MB/s
./server single
(only a single client talks to the server)
./client sync 4096 1000000
10.980143 s, 91073 msg/s, 11.0 us/msg, 355.733 MB/s
./client async 4096 1000000
3.041953 s, 328736 msg/s, 3.0 us/msg, 1284.044 MB/s
In all cases 1 msg means "send request + receive response".
Johannes
View attachment "server.c" of type "text/x-csrc" (2339 bytes)
View attachment "client.c" of type "text/x-csrc" (2662 bytes)
View attachment "Makefile" of type "text/plain" (80 bytes)
Powered by blists - more mailing lists