Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753025AbbFVVYM (ORCPT ); Mon, 22 Jun 2015 17:24:12 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:33434 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbbFVVYF (ORCPT ); Mon, 22 Jun 2015 17:24:05 -0400 Date: Mon, 22 Jun 2015 23:24:01 +0200 From: =?UTF-8?B?SmluZMWZaWNoIE1ha292acSNa2E=?= To: Linus Torvalds Cc: Andy Lutomirski , 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 Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150622232401.7d3f105a@holly> In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1732 Lines: 43 On Mon, 27 Apr 2015 15:14:49 -0700 Linus Torvalds wrote: > On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds > wrote: > > > > 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. > > 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 scheduler overhead *might* be 1% or so. > > So really. The people who talk about how kdbus improves performance > are just full of sh*t. Yes, it improves things, but the improvement > seems to be 100% "incidental", in that it avoids a few trips down the > user-space problems. > > 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. In case someone actually still reads this, I guess the global rw_lock in gobject/gtype.c, used by the GDbus binding, is one of the culprits. Every GType instance allocation/ deallocation is serialized using this lock, which pretty much disqualifies GObject from being used for anything scalable to multiple threads. GStreamer used to have serious performance issues due to that, which AFAIK have been solved by removing GType from GStreamer core in the 1.0 release. Regards, -- Jindrich Makovicka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/