Kdbus meets linux-kernel

Kdbus meets linux-kernel

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)?