Kdbus meets linux-kernel [LWN.net]

Kdbus meets linux-kernel

Posted Nov 6, 2014 2:47 UTC (Thu) by quotemstr (subscriber, #45331)
Parent article: Kdbus meets linux-kernel

At a fundamental level, I still don't understand what we can achieve by adding a new IPC primitive to the kernel that we can't achieve by adding a few features to AF_UNIX and a few new sendmsg flags.

to post comments

Kdbus meets linux-kernel

Posted Nov 6, 2014 4:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

One of the major DBUS features is multicasting and asynchronous signals.

There were patches to add multicast to AF_UNIX sockets but the network maintainer was a major roadblock. He basically told the kdbus developers to !@ck off and use IP multicasting for it. And that he wouldn't merge kdbus no matter how well it's written.

Kdbus meets linux-kernel

Posted Nov 6, 2014 10:28 UTC (Thu) by etienne (guest, #25256) [Link]

> One of the major DBUS features is multicasting and asynchronous signals.

Just two simple questions, from a non specialist:
DBUS requests looks a bit like SNMP, and even if SNMP docs is real crap it is reasonably easy to use - what would be the major difference between them?
(It would be nice to be able to ask another computer which timezone it is living in)

Adding multicast to AF_UNIX sockets is maybe wrong, but is it really less efficient to talk over an IP sockets to localhost (some short-circuit and zero copy network drivers are already probably implemented, isn't it)?

Kdbus meets linux-kernel

Posted Nov 6, 2014 8:48 UTC (Thu) by alexl (guest, #19068) [Link] (2 responses)

At a fundamental level it is not needed. In fact, we have dbus implementation that are not in the kernel. All that is needed to implement such a userspace dbus is a minimal way to connect to a socket and send bits (and optionally pass fd:s).

However, being in the kernel has certain advantages:

* Routing can use less context switches
The non-kernel dbus has to do the routing in a daemon process that all
clients connect to. This means any message needs to be sent first to the
daemon and then to the target process. In the kernel we can route direct from source to target process.

* Less copying of messages
As per the above, we need to copy and parse the message into the daemon
process first, and then into the destination.

* Security verification can be done in the kernel
Atm the dbus daemon applies things like uid limits and selinux policy on
dbus messages. If this is done in the kernel there is a higher level of
trust and auditing of this.

There has been multiple tries to make dbus work in the kernel. Some have involved modifying AF_UNIX or making a new network domain that have some of the dbus semantics. However, they have all been shot down by the network subsystem maintainer with permanent NACKs. This is why this new version uses device nodes instead.

Kdbus meets linux-kernel

Posted Nov 8, 2014 22:28 UTC (Sat) by suckfish (guest, #69919) [Link]

I'm very much reminded of the situation with the tux in-kernel-HTTP-server around a decade ago.

There, putting HTTP in-kernel was proposed for reasons with much in common with those stated for kdbus.

In that case, the outcome was that over a period of some time, tux's goals were broken down into a (fairly small) set of very generic in-kernel functionality.

This was pleasantly win-win : not only was the generic functionality useful outside of HTTP-servers, from memory the result was better for HTTP usage also.

[A couple of other success stories of breaking out kernel-space primitives from complex user-space systems spring to mind also: X11 and pthreads.]

Kdbus meets linux-kernel

Posted Nov 13, 2014 21:52 UTC (Thu) by oak (guest, #2786) [Link]

From analyzing DBUS daemon on mobile devices (nearly a decade ago), I remember DBUS daemon having following performance issues:

Latency: context switching issue could be solved just by specifying suitably sized (smaller than default) socket buffers for the daemon.
Throughput: daemon did internally so much marshaling & demarshaling that instead of it being IO-bound (like it should), it was CPU bound. Has it been fixed yet to do marshal & demarshal only once per message?
Message buffering: this was both daemon implementation & protocol issue. Multiple processes subscribed to system status messages that could be generated in huge amounts, and recipients of those messages may get frozen e.g. by container groups.

Until recipients read their messages, daemon buffers them, and DBUS daemon could (easily) become largest memory user in the system. After recipients were unfrozen, system spent also a lot of CPU churning through all the buffered messages, although only last one of them was relevant. In many cases D-BUS didn't return most of the memory dirtied by the buffering back to system because of DBUS allocator memory fragmentation.

In that particular device/setup this problem could be worked around by recipients unsubscribing from those messages before they got into a situation where they could be frozen. I think proper solution would have been a new "status" message type, for which daemon would store just the last one version per recipient.

What would happen with system kbus in similar situation, if frozen recipient is being constantly sent e.g. audio data (this was mentioned as one of the use-cases for kdbus by Greg)?