Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1179126 > unrolled thread

Re: [GIT PULL] kdbus for 4.1-rc1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [GIT PULL] kdbus for 4.1-rc1 Johannes Stezenbach <js@sig21.net> - 2015-07-08 00:30 +0200

#1179126 — Re: [GIT PULL] kdbus for 4.1-rc1

[Multipart message — attachments visible in raw view] — view raw

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@linux-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

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web