Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 4 Aug 2015 17:18:00 -0700 | Subject | Re: kdbus: to merge or not to merge? |
| |
On Tue, Aug 4, 2015 at 7:47 AM, Andy Lutomirski <luto@amacapital.net> wrote: > On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <dh.herrmann@gmail.com> wrote: >> Hi >> >> On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >>> On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann <dh.herrmann@gmail.com> wrote: >>>> >>>> You lack a call to sd_bus_unref() here. >>> >>> I assume it was intentional. Why would Andy talk about "scaling" otherwise? > > It was actually an error. I assumed that, since the user version > worked fine (at least for as long as I ran it) and the kernel version > didn't (killed X and left a blinking cursor, no visible log messages > even when run from a text console, and no obvious OOM recovery after a > long wait) that it was a kdbus issue or issue with other kdbus > clients. > > I'll play with it more today. >
I added the missing sd_bus_unref call.
With userspace dbus, my program takes 95% CPU and dbus-daemon takes 88% CPU or so.
With kdbus, I see abuse-bus (my test), systemd-journald, systemd-bus-proxy, auditd, gnome-shell, mission-control, sedispatch, firewalld, polkitd, NetworkManager, systemd, avahi-daemon, audisp, abrt-dump-jour* (whatever it's called -- it truncated), upowerd, and systemd-logind all taking tons of CPU. I've listed them in decreasing order of amount of CPU burned -- the top several are taking about as much as is possible. Load average is over 13. That's if I run it from a text console while I'm logged in to gnome in a different VT.
If I run the program from a graphical terminal, everything freezes so hard that the cursor doesn't even make it to the next line when I hit enter.
So I still claim that kdbus doesn't scale. I'm not even just saying that it doesn't scale to large systems -- somewhat to my surprise, it doesn't even seem to scale well enough for a mostly empty Rawhide workstation system running just a graphical terminal. And I didn't even try to find stress tests more interesting than connecting and disconnecting in a loop.
FWIW, the old test (without the unref) appeared to be allocating 16M of mapped kdbus pool every iteration, which seems unlikely to have helped matters.
--Andy
| |