33 ms·

“DBus is seriously screwed up”

281 points by deng 12y ago

christianbryant 12y ago
And https://lwn.net/Articles/636997/ https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.
- rdtsc 12y ago
  Good link. As a side note, I see sorokin's posts about DCOM, RPC and multi-threading: > Probably some unique thread-id can be propagated through the calls. And if incoming call has the same thread-id as one of our outgoing call it is handled inside this outgoing call as in nested message loop, otherwise a new thread from thread pool is used. This will create an illusion that two processes share the same set of threads and it works well with mutexes. I think he is slowly driving towards an actor like message passing thing like Erlang, Akka or Orleans without even realizing. Which reminds me of Virding's law: http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-... --- Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. ---
- userbinator 12y ago
  alternatives, solutions, or closure The link you posted has what I think is the right one: The problem is that probably this code is not needed at all. To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.
  - bandrami 12y ago
    there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."
    - digi_owl 12y ago
      Freedesktop was a interesting idea at the outset, but has since grown into what seems like another branch of RH alongside Fedora and Gnome.
  - bitwize 12y ago
    To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place: https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8649459 https://news.ycombinator.com/item?id=8649459 D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion. It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code. Oh, and it also does multicast, which no other commonly used Unix IPC can do. People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services.
    - chris_wot 12y ago
      Is there a document that explains the why's and wherefores of dbus? Aside from those posts.
      - teddyh 12y ago
        You can probably find it here: https://wiki.freedesktop.org/www/Software/dbus/ https://wiki.freedesktop.org/www/Software/dbus/
        tobik 12y ago
        Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc. What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc. The Wikipedia article on IPC https://en.wikipedia.org/wiki/Inter-process_communication https://en.wikipedia.org/wiki/Inter-process_communication is really incomplete.
  - byuu 12y ago
    > DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. It would seem that modern computing is all about building abstractions on top of abstractions, to solve 'problems' nobody ever had. Nobody ever seems to consider the costs of such complexity (in terms of maintenance, understanding the system as a whole, attack vectors, etc.) By all means, if you need a super complex system with tons of features like D-bus, great! But I am pretty confident that Mousepad (Xfce text editor) doesn't need D-bus just to open a text file in a new tab of an existing window.
    - coldtea 12y ago
      >Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. Is that sarcasm, or you don't know what dbus is used for?
      - byuu 12y ago
        > Is that sarcasm, or you don't know what dbus is used for? I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD. "D-Bus is a message bus system, a simple way for applications to talk to one another." With shared memory (IPC) or sockets (RPC), applications can talk to each other. Yes, D-Bus gives you an API interface for this (though I personally can't stand it); which apparently comes with tremendous overhead, if the linked article is to be believed. Yes, with raw memory/sockets, you have to do the queue work yourself. But that's CS101 stuff; you shouldn't touch IPC if you can't implement a simple shared queue. For most use cases, D-Bus is like using a jackhammer to nail in drywall. "In addition to interprocess communication ... it makes it simple and reliable to code a "single instance" application or daemon" Again, very easy with shared memory and a semaphore. If your attempt to open the semaphore fails, you create it and become the daemon. When the daemon closes, you delete the semaphore. When a second instance opens and connects to the semaphonre, and then shared memory, then it writes the command-line arguments into the queue, and the daemon handles it. Voila, "single instance" application or daemon. "and to launch applications and daemons on demand when their services are needed" And this would be a more complex use case that would be harder to solve. It's also a much less common use case. I don't really feel it's directly related to basic IPC, it's D-Bus trying to solve multiple problems at the same time. I'd rather follow the Unix way and split that into a separate component, perhaps built on top of the IPC protocol.
  - digi_owl 12y ago
    DBUS is a "weird" one. It came out of the initial freedesktop project to improve interaction between KDE and Gnome. KDE already had system called DCOP for internal use (allowed for instance Konqueror to be web browser, file manager and multi-pane FTP/SFTP client all at once). But as with much of KDE it was created using C++. And Gnome is made using C. So DBUS is something like a reimplementation of DCOP in C. And the rest is history...
- bitwize 12y ago
  People have come up with alternatives. They are: * AF_BUS, a new socket address family that provides a "generic" bus * adding multicast and order guarantees to AF_UNIX sockets None of these have the political traction that kdbus has. Kdbus, systemd, etc. get mainstreamed because they have top developers gunning for them being mainstreamed. The people on the sidelines going "but muh unix" are also-ran haters, nothing more. So let's just throw the switch and fry this sucker.
- deleted 12y ago
  [deleted]
joelthelion 12y ago
He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).
- TD-Linux 12y ago
  I agree, the OP title is a bit misleading. I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.
  - reidrac 12y ago
    I made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code. When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :( That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crashes; NM was 0.8 back then), but when I read Linus comments I can help to think he's probably right. This is an anecdote and all, but my point is that until I had to use it... DBUS was pretty good and was working fine :)
    - belorn 12y ago
      Were you using threads? Python really should not crash, but combine it with library imports implemented in c and threads, and you get really subtle race conditions which result in segfaults. I have myself been force to debug why Python segfaulted, and it was a standard library call which internally used threading, and that caused a conflict with a c library that was not threading safe.
      - reidrac 12y ago
        Sorry, it wasn't Python. It was a system component that crashed as consequence of my Python code using DBUS.
castell 12y ago
> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years. The component format (if you call it that way) that just works is HTML5. Edit: okay, it seems it's a controversial topic (My comment used examples which were DCOM and OLE 1+2 (the original MS Office thing "Compound document") - http://en.wikipedia.org/wiki/Object_Linking_and_Embedding http://en.wikipedia.org/wiki/Object_Linking_and_Embedding and http://en.wikipedia.org/wiki/Compound_document http://en.wikipedia.org/wiki/Compound_document , not COM directly)
- vidoc 12y ago
  The problem with REST is that it's great for what it was intended to do initially, but there are too many engineers that don't take their medication that actually use it to do RPC :P
- lclarkmichalek 12y ago
  Naive REST (HTTP, JSON) isn't exactly known for its performance
  - vidoc 12y ago
    Agreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P
    - bitwize 12y ago
      It's called Plan 9. In Plan 9, each process has its own filesystem tree, and other programs can expose themselves to this process as file servers, meaning that data internal to the programs can be accessed via the same read, write, delete, etc. calls as files. For example, when running under rio, the Plan 9 window system, the current window contents are available at /dev/window and you can write draw calls to /dev/draw to do graphics. REST is pretty much applying Plan 9 principles to the Web and http.
lmedinas 12y ago
Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
- pmr_ 12y ago
  You are not quoting the part where he shows his benchmark results, analysis of the problem, and suggested solution. I don't necessarily agree with Linus' tone or choice of words, but what you are doing is far worse. I'm not even sure if you are trying to be sarcastic, but that does not even matter: You are not contributing anything either way.
  - lmedinas 12y ago
    I have made an observation from Linus comments which is sad specially to people who worked on KDbus all this time. If you think your comment helped anything maybe you should consider making them when you see comments like the next one: quote: """ amelius 3 hours ago Should be rewritten in Erlang or Go, if you'd ask me. """ otherwise you are full of sh*t. :)
- mwfunk 12y ago
  As entertaining as it might be to people who are entertained by such things ("not me" would be an extreme understatement), it's pretty much exhibit A for Linus' inability to manage people in addition to code. It's embarrassing, honestly.
  - anon4 12y ago
    Well, as Eric put it At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.
- hp 12y ago
  Linus is mixing together two different performance issues. http://article.gmane.org/gmane.linux.kernel/1939651 http://article.gmane.org/gmane.linux.kernel/1939651 kdbus is solving an "architecture" issue that would affect any binding, while his profile is essentially of the gdbus binding.
vidoc 12y ago
It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.
- deng 12y ago
  That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.
  - lmilcin 12y ago
    I would expect any half decent HTTP server to be able to handle more messages per second than that. If that is going to be the future fabric underlying all application ecosystem on Linux I would be as wary of it as Linus is. I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.
    - azernik 12y ago
      Well, he's not claiming that kdbus is that slow. He's claiming that kdbus is faster not because it's in the kernel, but because it's not shitty code like userspace dbus (completely different implementation).
  - fulafel 12y ago
    So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
pjc50 12y ago
Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy. The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com/item?id=9450988 https://news.ycombinator.com/item?id=9450988 ; but if that's not popular, then I think what people actually want for desktop purposes is an equivalent of the Windows PostMessage system.
- XorNot 12y ago
  Plan 9 in no way implies performance. Just because you can make it look like a filesystem, doesn't mean it actually is going to achieve anything special performance wise.
  - jff 12y ago
    And in fact the performance of Plan 9 tended to be extremely poor when compared apples-to-apples with Linux. It's just that everything was so simple it felt fast, even if your filesystem throughput was crap.
- bitwize 12y ago
  > But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT overtook commercial Unix in the enterprise space. (Monopoly schmonopoly: Windows was the better platform. It was easy to develop for and relatively uniform across desktop and server deployments.) The Unix philosophy has proven inadequate to meet the needs of real-world software integration: what's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. D-bus provides that for Linux and no one so far has presented a better solution. As for Plan 9... yes, that's what you get when you apply the Unix philosophy in the extreme. Note that the UX for Plan 9 sucks, and if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.
lmilcin 12y ago
It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zlib), parses it, analyzes it, sends to multiple algorithms which decide if current market situation matches certain rules, decides and fills market order, the order gets inspected by independent mechanism to stop the algorithm if it malfunctions, and only then it gets sent to market, over TCP, which is another form of IPC. All in the span of fricking 5us which is 40 times less than the benchmark suggests for this simple task. Granted, the algorithmic trading world goes to great lengths to avoid overhead including kernel overhead any kind of task switiching, branch prediction fails, etc. But still, come on, guys...
- the_mitsuhiko 12y ago
  > It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.
  - huhtenberg 12y ago
    Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?
    - the_mitsuhiko 12y ago
      > If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything. There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.
acqq 12y ago
The Linus' explanation is here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... "Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture." "The real problems seem to be in dbus memory management (suggestion: keep a small per-thread cache of those message allocations) and to a smaller degree in the crazy utf8 validation (why the f*ck does it do that anyway?), with some locking problems thrown in for good measure. "
userbinator 12y ago
I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code": - Memory allocation/deallocation are taking the most time. - All the percentages for each function are very small. The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would malloc()/free() frivolously when something simpler would suffice. This is also often accompanied by copious amounts of unnecessarily copying data around. I've worked with small embedded systems where every use of dynamic allocation would need to be justified thoroughly in code reviews; perhaps these developers would benefit from being put through the same process. The latter is a phenomenon which arises from "excessive modularity": the functionality of the system has been split into so many little pieces that the time each function contributes to the overall total is tiny. Instead of seeing an obvious "80% of the time is being spent here" that could easily be targeted for optimisation, that 80% is scattered amongst several dozen functions each taking 1-2% each. The bottleneck isn't concentrated in one area --- the whole system is uniformly inefficient. It's extremely difficult to optimise a system like this because nothing in particular stands out as being optimisable. I've had to optimise some large Java applications that were like this, and the solution was basically to remove most of the code and rewrite it to get rid of many chains of indirection.
- avar 12y ago
  The way you generally deal with the second problem is to have a profiler that can give you the inclusive time spent in a subroutine, not just the exclusive time. The inclusive time is the time spent in that sub and in subs it calls, the exclusive time is time spent only in that sub. When you have inclusive time it usually becomes easy to find that function that's spending 80% of the time in either itself or in the things it calls.
- FeepingCreature 12y ago
  Somebody should modify perf to log "time spent in call", "time spent in stackframe setup", "time spent in mov", "time spent in branches", etc.
  - 12y ago
GutenYe 12y ago
What's potato, as said in the mailing list?
- Sharlin 12y ago
  Internet slang for a device, often a camera, of poor quality or outdated technology. http://www.urbandictionary.com/define.php?term=potato&defid=6321730 http://www.urbandictionary.com/define.php?term=potato&defid=...
- kzrdude 12y ago
  jargon for slow computer or old smartphone.
amelius 12y ago
Should be rewritten in Erlang or Go, if you'd ask me.
- deleted 12y ago
  [deleted]
- JosephRedfern 12y ago
  Are you missing '/s'?
kzrdude 12y ago
But this doesn't benchmark systemd's userland dbus implementation. That one is much better, right?
- codys 12y ago
  I hope so, but no one except systemd is using it yet. Last time I checked the sd-bus.h header isn't installed with systemd yet due to the systemd folks concern that that API for sd-bus wasn't finalized yet. It would be very interesting to benchmark it against the glib implementation (which most people, even if they aren't using glib directly, are using these days).
hp 12y ago
The Linus profile is mostly a red herring here, because it is 1) a bad benchmark with a bunch of blocking round trips and 2) mostly profiling the gdbus bindings which are just one binding. For a more in-depth performance discussion of dbus, check out http://lists.freedesktop.org/archives/dbus/2012-March/015024.html http://lists.freedesktop.org/archives/dbus/2012-March/015024... Above noted on linux-kernel here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939533 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
- zurn 12y ago
  The PDF link is sadly dead... (The ml message references heavily to the PDF)
outworlder 12y ago
This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some of my former coworkers to contact me with concerns about DBus. We used it pretty heavily. As for DBus itself: guys, it is useful. It works. You can count on it being there and working in most distributions, you can talk to most things nowadays. Its easy to use (for most use cases), language bindings are everywhere. So, turns out is slow. It's so cool that we have identified that. Let's fix it. Even if the slowness doesn't seem to bother many of its use cases.
- ChuckMcM 12y ago
  I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate. If it is any consolation, while I worked at Sun in the kernel group and later, this sort of 'cherry pick a message to start a debate' technique was also present. Sometimes it is just someone who believes something is broken and they use the message to bolster their argument.
  - nitrogen 12y ago
    I also wonder if the reverse happens, with people sabotaging the system by breaking things that work, making easy things harder, and replacing fast things with slower things.
    - felixgallo 12y ago
      I don't think it's fair to call systemd or dbus sabotage. It's entirely possible to construct explanations that rely on blinkered, tasteless incompetence, naivete, and personality cults rather than maliciousness.
kasabali 12y ago
I still fail to see why we need DBUS in kernel, so please correct me and clear my lack of understanding. It is claimed userspace dbus performance is bad, but people want to use it in a much larger scale, so what I deduce from that is there is nobody using dbus on that scale right now, since its performance sucks. Reason for getting kdbus into kernel, and not a generic ipc but specifically kdbus, is because user space that depends on dbus will continue to work with kdbus. What I still don't understand is, what is the point of keeping compatibility of currently non-existing userspace, if software that depend on dbus right now doesn't need performance enhancements and can just keep using regular dbus, and software that need high performance bus doesn't even use dbus since it's slow? Under these circumstances, why they insist on making kdbus strictly a dbus implementation but not a more generic ipc mechanism?
thuffy 12y ago
Let's talk about the elephant in the room. This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel. They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux. First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.
- antocv 12y ago
  systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa. Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.
  - thuffy 12y ago
    I absolutely agree it is a mess for other reasons as well; but let us attack it on all angles, and I think security is the most important one these days.
xorcist 12y ago
Now is the time for Linus to disappear for a few days, and re-emerge with a sane IPC design that both binder and dbus can build on. Bootstrapped in itself, of course :) (I have no idea what that would even mean in this context. But hey, it's all wishful thinking, right?)
ohjesusthatguy2 12y ago
Can someone point out where the quote comes from? I'm not a DBus developer but I'd like to know why the subject is what it is, and not something like "Issues with capability bits and meta-data in kdbus" or "Kdbus needs meaningful review".
phjesusthatguy3 12y ago
Can someone point out where the quote comes from? I'm not a DBus developer but I'd like to know why the subject is what it is, and not something like "Issues with capability bits and meta-data in kdbus" or "Kdbus needs meaningful review".
- hp 12y ago
  It's Linus being hyperbolic. Read follow-ups in the linux-kernel thread to see more specifically what these benchmarks mean.
supertruth 12y ago
Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling. Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument. He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck. But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.
- voidz 12y ago
  Responses like yours are why I enjoy to visit Hacker News. Sorry for going meta - I'm just a bit disappointed because your tone used to be the normal thing on HN, even when there were just as many disagreements. People were able to keep it friendly. Today not as much; I find HN has become too mainstream and "reddity", and the tone in general too emotional and aggressive, about who or what is right. This wasn't unexpected, but still, it is good to see not everyone has moved into that direction.

281 points by deng 12y ago

And https://lwn.net/Articles/636997/ https://lwn.net/Articles/636997/ But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.

rdtsc 12y ago
Good link. As a side note, I see sorokin's posts about DCOM, RPC and multi-threading: > Probably some unique thread-id can be propagated through the calls. And if incoming call has the same thread-id as one of our outgoing call it is handled inside this outgoing call as in nested message loop, otherwise a new thread from thread pool is used. This will create an illusion that two processes share the same set of threads and it works well with mutexes. I think he is slowly driving towards an actor like message passing thing like Erlang, Akka or Orleans without even realizing. Which reminds me of Virding's law: http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-... --- Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. ---
userbinator 12y ago
alternatives, solutions, or closure The link you posted has what I think is the right one: The problem is that probably this code is not needed at all. To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives.
- bandrami 12y ago
  there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."
  - digi_owl 12y ago
    Freedesktop was a interesting idea at the outset, but has since grown into what seems like another branch of RH alongside Fedora and Gnome.
- bitwize 12y ago
  To me, DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place: https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8649459 https://news.ycombinator.com/item?id=8649459 D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion. It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code. Oh, and it also does multicast, which no other commonly used Unix IPC can do. People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services.
  - chris_wot 12y ago
    Is there a document that explains the why's and wherefores of dbus? Aside from those posts.
    - teddyh 12y ago
      You can probably find it here: https://wiki.freedesktop.org/www/Software/dbus/ https://wiki.freedesktop.org/www/Software/dbus/
      - tobik 12y ago
        Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc. What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc. The Wikipedia article on IPC https://en.wikipedia.org/wiki/Inter-process_communication https://en.wikipedia.org/wiki/Inter-process_communication is really incomplete.
- byuu 12y ago
  > DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. It would seem that modern computing is all about building abstractions on top of abstractions, to solve 'problems' nobody ever had. Nobody ever seems to consider the costs of such complexity (in terms of maintenance, understanding the system as a whole, attack vectors, etc.) By all means, if you need a super complex system with tons of features like D-bus, great! But I am pretty confident that Mousepad (Xfce text editor) doesn't need D-bus just to open a text file in a new tab of an existing window.
  - coldtea 12y ago
    >Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. Is that sarcasm, or you don't know what dbus is used for?
    - byuu 12y ago
      > Is that sarcasm, or you don't know what dbus is used for? I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD. "D-Bus is a message bus system, a simple way for applications to talk to one another." With shared memory (IPC) or sockets (RPC), applications can talk to each other. Yes, D-Bus gives you an API interface for this (though I personally can't stand it); which apparently comes with tremendous overhead, if the linked article is to be believed. Yes, with raw memory/sockets, you have to do the queue work yourself. But that's CS101 stuff; you shouldn't touch IPC if you can't implement a simple shared queue. For most use cases, D-Bus is like using a jackhammer to nail in drywall. "In addition to interprocess communication ... it makes it simple and reliable to code a "single instance" application or daemon" Again, very easy with shared memory and a semaphore. If your attempt to open the semaphore fails, you create it and become the daemon. When the daemon closes, you delete the semaphore. When a second instance opens and connects to the semaphonre, and then shared memory, then it writes the command-line arguments into the queue, and the daemon handles it. Voila, "single instance" application or daemon. "and to launch applications and daemons on demand when their services are needed" And this would be a more complex use case that would be harder to solve. It's also a much less common use case. I don't really feel it's directly related to basic IPC, it's D-Bus trying to solve multiple problems at the same time. I'd rather follow the Unix way and split that into a separate component, perhaps built on top of the IPC protocol.
- digi_owl 12y ago
  DBUS is a "weird" one. It came out of the initial freedesktop project to improve interaction between KDE and Gnome. KDE already had system called DCOP for internal use (allowed for instance Konqueror to be web browser, file manager and multi-pane FTP/SFTP client all at once). But as with much of KDE it was created using C++. And Gnome is made using C. So DBUS is something like a reimplementation of DCOP in C. And the rest is history...
bitwize 12y ago
People have come up with alternatives. They are: * AF_BUS, a new socket address family that provides a "generic" bus * adding multicast and order guarantees to AF_UNIX sockets None of these have the political traction that kdbus has. Kdbus, systemd, etc. get mainstreamed because they have top developers gunning for them being mainstreamed. The people on the sidelines going "but muh unix" are also-ran haters, nothing more. So let's just throw the switch and fry this sucker.
deleted 12y ago
[deleted]

joelthelion 12y ago

He's not saying DBus as a concept is bad, just that the implementation sucks. If he's right, that's something that can be fixed relatively easily (compared to a major architectural change).

TD-Linux 12y ago
I agree, the OP title is a bit misleading. I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.
- reidrac 12y ago
  I made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code. When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :( That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crashes; NM was 0.8 back then), but when I read Linus comments I can help to think he's probably right. This is an anecdote and all, but my point is that until I had to use it... DBUS was pretty good and was working fine :)
  - belorn 12y ago
    Were you using threads? Python really should not crash, but combine it with library imports implemented in c and threads, and you get really subtle race conditions which result in segfaults. I have myself been force to debug why Python segfaulted, and it was a standard library call which internally used threading, and that caused a conflict with a c library that was not threading safe.
    - reidrac 12y ago
      Sorry, it wasn't Python. It was a system component that crashed as consequence of my Python code using DBUS.

castell 12y ago

> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years. The component format (if you call it that way) that just works is HTML5. Edit: okay, it seems it's a controversial topic (My comment used examples which were DCOM and OLE 1+2 (the original MS Office thing "Compound document") - http://en.wikipedia.org/wiki/Object_Linking_and_Embedding http://en.wikipedia.org/wiki/Object_Linking_and_Embedding and http://en.wikipedia.org/wiki/Compound_document http://en.wikipedia.org/wiki/Compound_document , not COM directly)

vidoc 12y ago
The problem with REST is that it's great for what it was intended to do initially, but there are too many engineers that don't take their medication that actually use it to do RPC :P
lclarkmichalek 12y ago
Naive REST (HTTP, JSON) isn't exactly known for its performance
- vidoc 12y ago
  Agreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P
  - bitwize 12y ago
    It's called Plan 9. In Plan 9, each process has its own filesystem tree, and other programs can expose themselves to this process as file servers, meaning that data internal to the programs can be accessed via the same read, write, delete, etc. calls as files. For example, when running under rio, the Plan 9 window system, the current window contents are available at /dev/window and you can write draw calls to /dev/draw to do graphics. REST is pretty much applying Plan 9 principles to the Web and http.

lmedinas 12y ago

Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

pmr_ 12y ago
You are not quoting the part where he shows his benchmark results, analysis of the problem, and suggested solution. I don't necessarily agree with Linus' tone or choice of words, but what you are doing is far worse. I'm not even sure if you are trying to be sarcastic, but that does not even matter: You are not contributing anything either way.
- lmedinas 12y ago
  I have made an observation from Linus comments which is sad specially to people who worked on KDbus all this time. If you think your comment helped anything maybe you should consider making them when you see comments like the next one: quote: """ amelius 3 hours ago Should be rewritten in Erlang or Go, if you'd ask me. """ otherwise you are full of sh*t. :)
mwfunk 12y ago
As entertaining as it might be to people who are entertained by such things ("not me" would be an extreme understatement), it's pretty much exhibit A for Linus' inability to manage people in addition to code. It's embarrassing, honestly.
- anon4 12y ago
  Well, as Eric put it At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.
hp 12y ago
Linus is mixing together two different performance issues. http://article.gmane.org/gmane.linux.kernel/1939651 http://article.gmane.org/gmane.linux.kernel/1939651 kdbus is solving an "architecture" issue that would affect any binding, while his profile is essentially of the gdbus binding.

vidoc 12y ago

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.

deng 12y ago
That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.
- lmilcin 12y ago
  I would expect any half decent HTTP server to be able to handle more messages per second than that. If that is going to be the future fabric underlying all application ecosystem on Linux I would be as wary of it as Linus is. I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.
  - azernik 12y ago
    Well, he's not claiming that kdbus is that slow. He's claiming that kdbus is faster not because it's in the kernel, but because it's not shitty code like userspace dbus (completely different implementation).
- fulafel 12y ago
  So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?

pjc50 12y ago

Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy. The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com/item?id=9450988 https://news.ycombinator.com/item?id=9450988 ; but if that's not popular, then I think what people actually want for desktop purposes is an equivalent of the Windows PostMessage system.

XorNot 12y ago
Plan 9 in no way implies performance. Just because you can make it look like a filesystem, doesn't mean it actually is going to achieve anything special performance wise.
- jff 12y ago
  And in fact the performance of Plan 9 tended to be extremely poor when compared apples-to-apples with Linux. It's just that everything was so simple it felt fast, even if your filesystem throughput was crap.
bitwize 12y ago
> But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT overtook commercial Unix in the enterprise space. (Monopoly schmonopoly: Windows was the better platform. It was easy to develop for and relatively uniform across desktop and server deployments.) The Unix philosophy has proven inadequate to meet the needs of real-world software integration: what's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. D-bus provides that for Linux and no one so far has presented a better solution. As for Plan 9... yes, that's what you get when you apply the Unix philosophy in the extreme. Note that the UX for Plan 9 sucks, and if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.

lmilcin 12y ago

It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zlib), parses it, analyzes it, sends to multiple algorithms which decide if current market situation matches certain rules, decides and fills market order, the order gets inspected by independent mechanism to stop the algorithm if it malfunctions, and only then it gets sent to market, over TCP, which is another form of IPC. All in the span of fricking 5us which is 40 times less than the benchmark suggests for this simple task. Granted, the algorithmic trading world goes to great lengths to avoid overhead including kernel overhead any kind of task switiching, branch prediction fails, etc. But still, come on, guys...

the_mitsuhiko 12y ago
> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.
- huhtenberg 12y ago
  Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?
  - the_mitsuhiko 12y ago
    > If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything. There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.

acqq 12y ago

The Linus' explanation is here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... "Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture." "The real problems seem to be in dbus memory management (suggestion: keep a small per-thread cache of those message allocations) and to a smaller degree in the crazy utf8 validation (why the f*ck does it do that anyway?), with some locking problems thrown in for good measure. "

userbinator 12y ago

I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code": - Memory allocation/deallocation are taking the most time. - All the percentages for each function are very small. The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would malloc()/free() frivolously when something simpler would suffice. This is also often accompanied by copious amounts of unnecessarily copying data around. I've worked with small embedded systems where every use of dynamic allocation would need to be justified thoroughly in code reviews; perhaps these developers would benefit from being put through the same process. The latter is a phenomenon which arises from "excessive modularity": the functionality of the system has been split into so many little pieces that the time each function contributes to the overall total is tiny. Instead of seeing an obvious "80% of the time is being spent here" that could easily be targeted for optimisation, that 80% is scattered amongst several dozen functions each taking 1-2% each. The bottleneck isn't concentrated in one area --- the whole system is uniformly inefficient. It's extremely difficult to optimise a system like this because nothing in particular stands out as being optimisable. I've had to optimise some large Java applications that were like this, and the solution was basically to remove most of the code and rewrite it to get rid of many chains of indirection.

avar 12y ago
The way you generally deal with the second problem is to have a profiler that can give you the inclusive time spent in a subroutine, not just the exclusive time. The inclusive time is the time spent in that sub and in subs it calls, the exclusive time is time spent only in that sub. When you have inclusive time it usually becomes easy to find that function that's spending 80% of the time in either itself or in the things it calls.
FeepingCreature 12y ago
Somebody should modify perf to log "time spent in call", "time spent in stackframe setup", "time spent in mov", "time spent in branches", etc.
- 12y ago

GutenYe 12y ago

What's potato, as said in the mailing list?

Sharlin 12y ago
Internet slang for a device, often a camera, of poor quality or outdated technology. http://www.urbandictionary.com/define.php?term=potato&defid=6321730 http://www.urbandictionary.com/define.php?term=potato&defid=...
kzrdude 12y ago
jargon for slow computer or old smartphone.

amelius 12y ago

Should be rewritten in Erlang or Go, if you'd ask me.

deleted 12y ago
[deleted]
JosephRedfern 12y ago
Are you missing '/s'?

kzrdude 12y ago

But this doesn't benchmark systemd's userland dbus implementation. That one is much better, right?

codys 12y ago
I hope so, but no one except systemd is using it yet. Last time I checked the sd-bus.h header isn't installed with systemd yet due to the systemd folks concern that that API for sd-bus wasn't finalized yet. It would be very interesting to benchmark it against the glib implementation (which most people, even if they aren't using glib directly, are using these days).

hp 12y ago

The Linus profile is mostly a red herring here, because it is 1) a bad benchmark with a bunch of blocking round trips and 2) mostly profiling the gdbus bindings which are just one binding. For a more in-depth performance discussion of dbus, check out http://lists.freedesktop.org/archives/dbus/2012-March/015024.html http://lists.freedesktop.org/archives/dbus/2012-March/015024... Above noted on linux-kernel here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939533 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

zurn 12y ago
The PDF link is sadly dead... (The ml message references heavily to the PDF)

outworlder 12y ago

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some of my former coworkers to contact me with concerns about DBus. We used it pretty heavily. As for DBus itself: guys, it is useful. It works. You can count on it being there and working in most distributions, you can talk to most things nowadays. Its easy to use (for most use cases), language bindings are everywhere. So, turns out is slow. It's so cool that we have identified that. Let's fix it. Even if the slowness doesn't seem to bother many of its use cases.

ChuckMcM 12y ago
I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate. If it is any consolation, while I worked at Sun in the kernel group and later, this sort of 'cherry pick a message to start a debate' technique was also present. Sometimes it is just someone who believes something is broken and they use the message to bolster their argument.
- nitrogen 12y ago
  I also wonder if the reverse happens, with people sabotaging the system by breaking things that work, making easy things harder, and replacing fast things with slower things.
  - felixgallo 12y ago
    I don't think it's fair to call systemd or dbus sabotage. It's entirely possible to construct explanations that rely on blinkered, tasteless incompetence, naivete, and personality cults rather than maliciousness.

kasabali 12y ago

I still fail to see why we need DBUS in kernel, so please correct me and clear my lack of understanding. It is claimed userspace dbus performance is bad, but people want to use it in a much larger scale, so what I deduce from that is there is nobody using dbus on that scale right now, since its performance sucks. Reason for getting kdbus into kernel, and not a generic ipc but specifically kdbus, is because user space that depends on dbus will continue to work with kdbus. What I still don't understand is, what is the point of keeping compatibility of currently non-existing userspace, if software that depend on dbus right now doesn't need performance enhancements and can just keep using regular dbus, and software that need high performance bus doesn't even use dbus since it's slow? Under these circumstances, why they insist on making kdbus strictly a dbus implementation but not a more generic ipc mechanism?

thuffy 12y ago

Let's talk about the elephant in the room. This is quite obviously the NSA adding massive additional attackable surface area to the Linux kernel. They did it to SSL/TLS, they did it to many others, they are now doing it in earnest to Linux. First systemd, now kdbus. Keep this up and OpenBSD, or something else, is going to kill the Swiss cheese that Linux is becoming. I love Linux, so it is sad to see this happening.

antocv 12y ago
systemd, kdbus and pulseaudio - wow r00t lol. kthxbai /nsa. Seriously, its already a huge mess to administate a GNU/Linux with systemd and dbus and polkit already as it is. Its the only parts of my system where I feel I cant really inspect its inner workings. Its a black box.
- thuffy 12y ago
  I absolutely agree it is a mess for other reasons as well; but let us attack it on all angles, and I think security is the most important one these days.

xorcist 12y ago

Now is the time for Linus to disappear for a few days, and re-emerge with a sane IPC design that both binder and dbus can build on. Bootstrapped in itself, of course :) (I have no idea what that would even mean in this context. But hey, it's all wishful thinking, right?)

ohjesusthatguy2 12y ago

Can someone point out where the quote comes from? I'm not a DBus developer but I'd like to know why the subject is what it is, and not something like "Issues with capability bits and meta-data in kdbus" or "Kdbus needs meaningful review".

phjesusthatguy3 12y ago

hp 12y ago
It's Linus being hyperbolic. Read follow-ups in the linux-kernel thread to see more specifically what these benchmarks mean.

supertruth 12y ago

Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling. Secondly, he's saying that if performance is being used as an argument for kdbus, then that's an invalid argument. He's totally right by the way. In this pure message-passing benchmark, where the message-passing overhead is the majority of the work, the slowness is not in kernel-scheduling/system-call/kernel-buffer-copies. People confused a potential impossible-to-overcome bottleneck as the most relevant bottleneck. But that doesn't mean there isn't a reason for kdbus. Kdbus allows for much better authentication than UNIX sockets do (you can authenticate with pid, pgid, uid, gid, kdbus token, etc.). Also it allows for message-passing security policies to live in the kernel which is crucial for security applications. The tangential performance benefits are nice too, even though the bottleneck wasn't in the kernel to begin with.

voidz 12y ago
Responses like yours are why I enjoy to visit Hacker News. Sorry for going meta - I'm just a bit disappointed because your tone used to be the normal thing on HN, even when there were just as many disagreements. People were able to keep it friendly. Today not as much; I find HN has become too mainstream and "reddity", and the tone in general too emotional and aggressive, about who or what is right. This wasn't unexpected, but still, it is good to see not everyone has moved into that direction.