Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753549AbbDUNiR (ORCPT ); Tue, 21 Apr 2015 09:38:17 -0400 Received: from mail-qk0-f171.google.com ([209.85.220.171]:32882 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538AbbDUNiP (ORCPT ); Tue, 21 Apr 2015 09:38:15 -0400 MIME-Version: 1.0 In-Reply-To: <20150421090721.GB20838@sig21.net> References: <20150420205638.GA3015@kroah.com> <55356CC1.1040301@nod.at> <20150421090721.GB20838@sig21.net> From: Havoc Pennington Date: Tue, 21 Apr 2015 09:37:44 -0400 X-Google-Sender-Auth: NIHyV97g8k9UR6-UuDppgI12CnQ Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Johannes Stezenbach Cc: Richard Weinberger , Greg Kroah-Hartman , David Herrmann , Linus Torvalds , Steven Rostedt , One Thousand Gnomes , Jiri Kosina , Al Viro , Borislav Petkov , Andy Lutomirski , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3028 Lines: 62 Hi, On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach wrote: > My line of thinking had been to amend DBus with optional direct > client/server communication for the performance critical > cases, since I believe those cases are RPC calls and not other > types of messaging (see also the "Performance" section in the > cover letter of this thread). (My other line of thinking had > been: if you need performance, don't use DBus e.g. in the > case of the tiny ARM systems sending hundreds of thousands of > messages during boot, quoted by Greg.) > This has long been sort of the 'party line' and I've told many people this on the dbus mailing list over the years (almost exactly what you just said - that for performance-critical cases they should open a direct socket or use something else or whatever). Usually this makes app developers a little cranky because something that was going to be easy in their mind just got harder. I think the pressure to use dbus happens for several reasons, if you use a side channel some example complaints people have are: * you have to reinvent any dbus solutions for security policy, containerization, debugging, introspection, etc. * you're now writing custom socket code instead of using the high-level dbus API * the side channel loses message ordering with respect to dbus messages * your app code is kind of "infected" structurally by a performance optimization concern * you have to decide in advance which messages are "too big" or "too numerous" - which may not be obvious, think of a cut-and-paste API, where usually it's a paragraph of text but it could in theory be a giant image * you can't do big/numerous multicast, side channel only solves the unicast There's no doubt that it's possible to use a side channel - just as it was possible to construct an ad hoc IPC system prior to dbus - but the overall OS (counting both kernel and userspace) perhaps becomes more complex as a result, compared to having one model that supports more cases. One way to frame it: the low performance makes dbus into a relatively leaky abstraction where there's this surprise lurking for app developers that they might have to roll their own IPC on the side or special-case some of their messages. it's not the end of the world, it's just that it would have a certain amount of overall simplicity (counting userspace+kernel together) if one solution covered almost all use-cases in this "process-to-process comms on local system" scenario, instead of 90% of use-cases but too slow for the last 10%. The simplicity here isn't only for app developers, it's also for anyone doing debugging or administration or system integration, where they can deal with one system _or_ one system plus various ad-hoc side channels. Havoc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/