Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753225AbbFVUYd (ORCPT ); Mon, 22 Jun 2015 16:24:33 -0400 Received: from mail.emea.novell.com ([130.57.118.101]:59454 "EHLO mail.emea.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751523AbbFVUYZ (ORCPT ); Mon, 22 Jun 2015 16:24:25 -0400 Date: Mon, 22 Jun 2015 22:23:56 +0200 (CEST) From: Jiri Kosina X-X-Sender: jikos@twin.jikos.cz To: Jindrich Makovicka cc: linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] kdbus for 4.1-rc1 In-Reply-To: Message-ID: References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 47 On Mon, 22 Jun 2015, Jindrich Makovicka 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 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. This is interesting piece of information, but you unfortunately dropped everybody from CC, so it's very likely that it's going to be lost in the noise. Could you please resend with CC list restored? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/