User: Password:
|
|
Subscribe / Log in / New account

Kroah-Hartman: Kdbus Details

In something of a follow-up to our coverage of the kdbus talk given at linux.conf.au by Lennart Poettering, Greg Kroah-Hartman has written a blog post giving more kdbus background. In particular, he looks at why kdbus will not be replacing Android's binder IPC mechanism anytime soon—if at all. "The model of binder is very limited, inflexible in its use-cases, but very powerful and extremely low-overhead and fast. Binder ensures that the same CPU timeslice will go from the calling process into the called process’s thread, and then come back into the caller when finished. There is almost no scheduling involved, and is much like a syscall into the kernel that does work for the calling process. This interface is very well suited for cheap devices with almost no RAM and very low CPU resources."
(Log in to post comments)

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 18:51 UTC (Thu) by iabervon (subscriber, #722) [Link]

The question I have about kdbus is: if you're a distro that hasn't managed to adopt systemd yet, can you replace the entirely-userspace dbus with kdbus? (Once kdbus is ready for prime time, of course, assuming you're still stuck with non-systemd at that time.)

Equivalently, as a developer using D-Bus, are you going to have to worry about your Linux builds being mysteriously glitchy on end user systems because you develop on a machine with systemd and they use Ubuntu?

It seems sensible that, if you are using systemd, your dbus-initiated services would actually be managed by systemd itself, while if you're not, they'd be managed by a daemon that just does userspace tasks for kdbus, but I haven't seen any confirmation that the second case is actually getting written by anyone.

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 20:09 UTC (Thu) by mezcalero (subscriber, #45103) [Link]

The userspace we wrote lives in the systemd repo, and you cannot really isolate out since it makes use of various systemd concepts for its implementation. For example, for activation we introduced the new ".busname" unit type, which then triggers a ".service" unit for the service process.

That all said, it is certainly possible to implement alternative userspace implementations, the kernel side is in no way bound to any specific userspace component.

I have no idea what Ubuntu's plans are. I cannot comment on that. They always figured something out, they'll figure something out this time, too. One option is to simply stay with dbus-daemon.

From our side, we certainly are working in getting the bits and pieces needed for making sure userspace implementations for kdbus stay interoperable into the official dbus spec.

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 22:48 UTC (Thu) by iabervon (subscriber, #722) [Link]

That's perfectly reasonable; I was just curious because udev is in the systemd repo, can run stuff, and works without systemd, so it wouldn't be unprecedented to support a non-systemd build for something similar.

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 21:11 UTC (Thu) by khim (subscriber, #9252) [Link]

The question I have about kdbus is: if you're a distro that hasn't managed to adopt systemd yet, can you replace the entirely-userspace dbus with kdbus? (Once kdbus is ready for prime time, of course, assuming you're still stuck with non-systemd at that time.)

AFAICS situation here is the same as with all other kernel changes. When glibc added few extensions for NPTL they were only tested with NPTL and glibc (needs of uClibc and dietlibc users were handled by uClibc and dietlibc developers, not by glibc developers), when KMS was introduced it was developed in parallel with X.org development and DirectFB and/or GGI developers were suppoosed to adapt (or not adapt) it.

Similarly here: existing implementation of the userspace part uses systemd and if someone wants to create an alternative version which does not need systemd s/he's free to do so, but why should developers of reference implementation of kdbus care about that?

Equivalently, as a developer using D-Bus, are you going to have to worry about your Linux builds being mysteriously glitchy on end user systems because you develop on a machine with systemd and they use Ubuntu?

The API exposed by libdbus is supposed to be identical in both cases. Of course if you rely on the ability to push gigabytes of data via the kdbus then this approach will not work without kdbus, but this is true for any kind of such improvement: if you program relies on fast fork then it'll be extremely slow on Windows in cygwin, but it's not a reason to add fast fork to an OS, right?

It seems sensible that, if you are using systemd, your dbus-initiated services would actually be managed by systemd itself, while if you're not, they'd be managed by a daemon that just does userspace tasks for kdbus, but I haven't seen any confirmation that the second case is actually getting written by anyone.

That's because people who don't use systemd have not did anything about it yet. Will they create a new version of daemon which will utilize kdbus or will they continue to use purely user-space driven implementation? It's up to them to decide, I guess. If you care that much about such distributions then you can probably write some kind of reference implementation (you may be able to find few glitches in the kdbus kernel side that way thus such contribution will be defenitely quite valuable), but if noone will do that then it'll just mean that kdbus will only be usable with a systemd for some time.

I'm more disturbed by the fact that binder is not implementable on top of kdbus: this means that mainstream Linux (which is undoubtedly called “Android” these days and not a “GNU/Linux”) will continue to diverge from legacy version more and more. I don't think it's good thing to have long-term, but I'm not sure what can be done about it (I'm not kernel guru thus I'll assume that if they say that it's impossible to create simple in-kernel API which can support both dbus and binder then they are right).

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 19:42 UTC (Thu) by proski (subscriber, #104) [Link]

If binder is so different from dbus and is not broken by design, shouldn't it be merged? The kernel supports several memory allocators, multiple I/O schedulers, a large variety of QoS algorithms. Why not have several IPC mechanisms?

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 19:45 UTC (Thu) by alexl (guest, #19068) [Link]

Kroah-Hartman: Kdbus Details

Posted Jan 16, 2014 19:53 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

To be fair, that is just the staging area. Typically things in staging needs quite a bit of work before it becomes part of the regular kernel.

Kroah-Hartman: Kdbus Details

Posted Jan 22, 2014 15:56 UTC (Wed) by BenHutchings (subscriber, #37955) [Link]

That version doesn't include donation of scheduler timeslices, as the scheduler doesn't expose such functionality to modules. (It does include priority inheritance though.)

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 6:55 UTC (Fri) by heijo (guest, #88363) [Link]

How does this handle the multicast problem?

That is, what happens if someone subscribes to a multicast data stream (I think they are called signals in D-BUS) and then doesn't read any data?

Does the publisher eventually block until the subscriber reads the data? Does the subscriber eventually get killed by the OOM killer? Is data discarded? Something else?

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 8:24 UTC (Fri) by oldtomas (guest, #72579) [Link]

> How does this handle the multicast problem?

I must admit that this intrigues me too. To me, "multicast" and "reliable" feels like an oxymoron, although I'm confident that the people involved are smart enough to have done the right thing (technically).

OTOH I was sufficiently disgusted by all the more "social" issues around that all that I haven't managed (yet?) to RTFD.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 8:54 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> That is, what happens if someone subscribes to a multicast data stream (I think they are called signals in D-BUS) and then doesn't read any data?

Well, in regular dbus-daemon everything blocks. That's why my kmail freezes when I killall -STOP chromium. It's annoying.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 10:58 UTC (Fri) by niner (subscriber, #26151) [Link]

So _that's_ the reason for those strange desktop freezes where most applications stop doing anything (even drawing their windows) for some time only to wake up later as if nothing happened. I always wondered since system load was quite normal during those periods and only desktop software seemed to be affected.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 22:13 UTC (Fri) by hp (subscriber, #5220) [Link]

No, that's not likely to be the reason (or at least, it's no more likely than anything else).

My guess on those freezes is that they're due to a broken use of blocking IO in your compositor (e.g. gnome-shell). But in theory any X client that grabs the display then blocks could cause this.

Saying "dbus can block" does not mean "all blocking is caused by dbus" (especially since apps don't have to block on dbus, even if dbus is blocking). Though I don't think dbus IS blocking, it's been a while so maybe I'm wrong.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 22:57 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> My guess on those freezes is that they're due to a broken use of blocking IO in your compositor (e.g. gnome-shell).

Not that I really disagree, but this "broken" behavior isn't always avoidable. There is one kind of I/O which is always blocking: page faults. Even if you don't have a swap file, code and read-only data is backed by the executable file on disk, and if virtual memory is accessed which isn't currently backed by RAM, the thread will block. Short of disabling swap and running from a RAM filesystem, I would say that the best approach here involves keeping disk latency low (so smaller I/O buffers, particularly anything shared between processes) and prioritizing the small disk reads needed to satisfy page faults over bulk data transfers.

Kroah-Hartman: Kdbus Details

Posted Jan 18, 2014 14:42 UTC (Sat) by heijo (guest, #88363) [Link]

Or call mlockall() the compositor.

Of course, that's much more feasible if one doesn't put the whole desktop UI inside the compositor.

Kroah-Hartman: Kdbus Details

Posted Jan 19, 2014 1:18 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

Even if you're not putting the entire desktop UI in the compositor, I'm not sure how feasible it is to fit even an minimalistic compositor in 64 kB of RAM, the maximum amount of memory lockable (by default) for non-root processes. You could raise the limit, or provide a SUID wrapper for the compositor, but either approach risks letting users starve the system of physical RAM.

For reference, the text section of twm alone is almost twice that. With the libraries, it's more like 34 MB, counting only mmap()'d disk space. A compositor, even a minimal one, would have to do everything twm does, plus the actual compositing.

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 12:50 UTC (Mon) by robbe (subscriber, #16131) [Link]

The xcompmgr binary is about 27kB in Debian stable on i386. With libraries, it's about 2 MiB, though.

Maybe the limit should have some relation to total RAM. But the notion of per-process limits seem antiquated anyway, when control groups are everywhere.

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 15:27 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> The xcompmgr binary is about 27kB in Debian stable on i386. With libraries, it's about 2 MiB, though.

Fair enough, though xcompmgr does not include window-manager functionality, so you would need to run a separate window manager and lock that into memory as well if you want a desktop guaranteed free of page faults.

I agree that control groups are preferable to per-process limits. Is there an existing control group for locked RAM?

Kroah-Hartman: Kdbus Details

Posted Jan 23, 2014 20:57 UTC (Thu) by cesarb (subscriber, #6266) [Link]

Every process already has at least 8KiB of locked memory (the process structure and the kernel stack), so a per-process limit for locked memory makes sense.

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 8:26 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> My guess on those freezes is that they're due to a broken use of blocking IO in your compositor (e.g. gnome-shell). But in theory any X client that grabs the display then blocks could cause this.

I don't think so. The symptoms are different - it's more selective and seemingly "random". For example kmail looks perfectly normal until I try to open a message - then it freezes for a duration that looks like a timeout somewhere. I can then switch to konsole just like any other day and killall -CONT chromium and kmail immediately springs back to life.

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 16:54 UTC (Mon) by hp (subscriber, #5220) [Link]

Oh, thought you were talking about a whole-desktop freeze.

For those symptoms it seems pretty clear that the app in question is just doing some blocking IO. This is not dbus's fault, it's the app's fault for waiting for the IO instead of doing it async.

Kroah-Hartman: Kdbus Details

Posted Jan 21, 2014 10:31 UTC (Tue) by jezuch (subscriber, #52988) [Link]

> For those symptoms it seems pretty clear that the app in question is just doing some blocking IO. This is not dbus's fault, it's the app's fault for waiting for the IO instead of doing it async.

Oh, I know an IO-related problem when I see one, and that's not it :) Especially not in kmail, where blocking IO does not block the UI.

Kroah-Hartman: Kdbus Details

Posted Jan 21, 2014 15:02 UTC (Tue) by hp (subscriber, #5220) [Link]

the only way to interact with dbus in any way is with IO. The only way dbus could block another process is if that IO was using a blocking IO API.

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 8:39 UTC (Mon) by niner (subscriber, #26151) [Link]

I don't always use a compositor. I've only recently started activating compositing in kwin, but have seen this behaviour for years. Really, blocking on dbus seems the most likely explanation, especially since like another comment just said, it does not block all applications. I can still use open konsole terminals but for example cannot open new ones.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 22:20 UTC (Fri) by hp (subscriber, #5220) [Link]

Something may have changed, but when I last hacked on dbus I don't think this was true that one stuck client could block the bus.

Now, one client can block ITSELF while waiting for a reply from another client - but this is the fault of the client for blocking instead of using async APIs. dbus-daemon will still be happily working fine and other clients should be working fine.

There are limits on how much dbus will buffer, so if a client isn't reading its inbox eventually some errors will be thrown. At least, that's my memory from a long time ago.

Kroah-Hartman: Kdbus Details

Posted Jan 17, 2014 21:06 UTC (Fri) by jonabbey (guest, #2736) [Link]

I'd love to know this as well. Given that kdbus has been described as asynchronous and as not guaranteeing ordered message delivery across multiple recipients, it seems that the publisher would just go one with what it was doing with its other correspondents while the unresponsive recipient timed out.

It'd be interesting to know how message lifetimes interact with process transitions. If the publisher process dies, that presumably immediately cancels any undelivered messages, right?

Kroah-Hartman: Kdbus Details

Posted Jan 18, 2014 6:25 UTC (Sat) by mezcalero (subscriber, #45103) [Link]

The same thing happens as with dbus-daemon. We put limits on everything, and eventually, when a client hits these limits regarding queued but unread messages it is assumed that the client is dead and kicked from the bus.

Kroah-Hartman: Kdbus Details

Posted Jan 19, 2014 17:50 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

What if it was misbehaving sender of multicast messages that sent too many messages was responsible for queue overflow, not the listener? Are there any plans to mitigate that?

Kroah-Hartman: Kdbus Details

Posted Jan 20, 2014 6:40 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

yes. any sender can only have a certain amount of messages queued and unanswered into other peers receive buffers. also every user can only have a maximum number of commections.

Kroah-Hartman: Kdbus Details

Posted Jan 19, 2014 23:35 UTC (Sun) by gb (subscriber, #58328) [Link]

> This interface is very well suited for cheap devices with almost no RAM and very low CPU resources.

This statement really miss the point. I'd rather say that "such approach means power efficiency and best latency in all cases".

Kroah-Hartman: Kdbus Details

Posted Jan 30, 2014 10:52 UTC (Thu) by minaev (guest, #95290) [Link]

Dbus is usually considered a desktop-specific service, it is not normally installed on servers. Is there any use in kdbus on servers? Will there be a way to disable it? Perhaps, the time has come to split the kernel into two flavors, a server kernel (no dbus, no hal, no systemd, etc) and a desktop one?

Kroah-Hartman: Kdbus Details

Posted Jan 30, 2014 14:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

While the "D" did indeed stand for "desktop" at one point, but I don't think it stands for anything anymore (similar to KDE's "K"). It's just an IPC mechanism at this point (that happened to start from desktop use cases).

Also, HAL has been dead and gone for a *long* time already and systemd isn't part of the kernel, but I see no reason to fork the kernel; just build your own if you have a niche.

Kroah-Hartman: Kdbus Details

Posted Jan 31, 2014 7:50 UTC (Fri) by minaev (guest, #95290) [Link]

It's not the 'D' why dbus is desktop-specific :). It's just not used in server software. For two reasons, IMHO. Firstly, because of its desktopish nature (like, local-only, no network; too high-level compared to traditional message passing APIs). And secondly, because of the short life span of technologies like the aforementioned hal, consolekit and, hopefully, dbus. This is why they should be placed in some kind of external DMZ instead of the proper kernel, in my poorly educated opinion, sorry :)

Kroah-Hartman: Kdbus Details

Posted Jan 31, 2014 13:42 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The local-only, no network comes from the fact that dbus can transport file descriptors and gives guarantees that a network would ruin. As for being "too high-level", do you shun all non-C daemons as well? And for the lifespan, dbus looks pretty strong to me. It has wide usage, is fairly bug free, and is a protocol. Plus it's seeing use in systemd which is being used in quite a lot of places (most of the big distros, LSB, RHEL, GENIVI, and more). Maybe an implementation would get rewritten, but I'd say dbus is here to stay for a long time.

Kroah-Hartman: Kdbus Details

Posted Feb 4, 2014 16:54 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> like, local-only, no network
D-Bus does have a TCP transport.

> too high-level compared to traditional message passing APIs
I don't see why having a high-level protocol is supposed to be a problem.

> And secondly, because of the short life span of technologies like the aforementioned hal, consolekit
Sorry, but this doesn't make any sense. D-Bus has nothing to do with either HAL or ConsoleKit.

Kroah-Hartman: Kdbus Details

Posted Jan 30, 2014 14:54 UTC (Thu) by cortana (subscriber, #24596) [Link]

dbus is no more a desktop-specific service than any other general purpose message bus. On my personal server it was pulled in murmurd, which exposes administration interfaces via dbus and/or ICE.

I imagine system administration would be fairly tedious without it as well, since systemctl uses it to talk to systemd (with a fallback to a root-only private socket direct to systemd for when the bus is down); and loginctl/hostnamectl/localectl/timedatectl use it to contact their corresponding daemons.

As far as I know, there was never anything of HAL in the kernel, and anyway it was long ago obsoleted by udev, logind, udisks & upower

Kroah-Hartman: Kdbus Details

Posted Jan 30, 2014 15:00 UTC (Thu) by vonbrand (guest, #4458) [Link]

That ship sailed quite a few years back...


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds