On Tue, Aug 4, 2015 at 7:47 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <dh.herrm...@gmail.com> wrote: >> Hi >> >> On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds >> <torva...@linux-foundation.org> wrote: >>> On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann <dh.herrm...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
