Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965650AbbD0WAQ (ORCPT ); Mon, 27 Apr 2015 18:00:16 -0400 Received: from mail-ie0-f180.google.com ([209.85.223.180]:34793 "EHLO mail-ie0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965213AbbD0WAK (ORCPT ); Mon, 27 Apr 2015 18:00:10 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> Date: Mon, 27 Apr 2015 15:00:09 -0700 X-Google-Sender-Auth: GflgjwxeJXEFIz1MmA7_rslCoNg Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: Linus Torvalds To: Andy Lutomirski Cc: Lukasz Skalski , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , 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: 2740 Lines: 68 On Mon, Apr 27, 2015 at 2:40 PM, Andy Lutomirski wrote: > > Change "USER" to "SESSION". That works. > Build with: Hell no. I used gcc client.c -o client $(pkg-config --cflags --libs gtk+-2.0) instead. That worked. >> That said, either you're running your test on a potato, or dbus is >> seriously screwed up. No way should it take 4+ seconds to send a 1000b >> message to back and forth 20k times. But as mentioned, I can't even >> see what it's doing right now. > > Whee! I'm typing this email on a potato! No, I think you're right, there's the other non-potato choice: "dbus is seriously screwed up". That thing has almost no kernel footprint. It's spending all it's time in user space overhead. Quite frankly, the whole "kdbus is important for performance" seems to be *totally* invalidated by even a minimal look at profiles for that thing. Here's the top-15 offender list: 2.62% gdbus libc-2.20.so [.] _int_malloc 2.43% gdbus libc-2.20.so [.] free 2.31% server libc-2.20.so [.] free 2.12% gdbus libc-2.20.so [.] malloc 1.77% gdbus libglib-2.0.so.0.4200.2 [.] g_utf8_validate 1.43% gdbus libglib-2.0.so.0.4200.2 [.] g_slice_alloc 1.41% gdbus libglib-2.0.so.0.4200.2 [.] g_hash_table_lookup 1.28% server libc-2.20.so [.] _int_malloc 1.27% gdbus libglib-2.0.so.0.4200.2 [.] g_mutex_lock 1.22% gdbus libglib-2.0.so.0.4200.2 [.] g_variant_unref 1.16% server libc-2.20.so [.] malloc 1.14% gdbus libglib-2.0.so.0.4200.2 [.] g_bit_lock 1.07% gdbus libglib-2.0.so.0.4200.2 [.] g_slice_free1 1.05% gdbus libglib-2.0.so.0.4200.2 [.] g_bit_unlock 1.01% gdbus libglib-2.0.so.0.4200.2 [.] g_mutex_unlock there's not a kernel function in sight in the top-15, and it's all just overhead. The above is from the server side, but the client looks similar. If somebody wants to speed up dbus, they should likely look at the user-space code, not the kernel side. My guess is that pretty much the entirely of the quoted kdbus "speedup" isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server. IOW, all the people who say that it's about avoiding context switches are probably just full of shit. It's not about context switches, it's about bad user-level code. Linus -- 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/