linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <mm9gsu$4cq$1@ger.gmane.org>
Date:	Mon, 22 Jun 2015 17:33:18 +0000 (UTC)
From:	Jindrich Makovicka <makovick@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote:

> On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> 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.

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/