Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965651AbbD0WaN (ORCPT ); Mon, 27 Apr 2015 18:30:13 -0400 Received: from mail.lang.hm ([64.81.33.126]:60062 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965201AbbD0WaL (ORCPT ); Mon, 27 Apr 2015 18:30:11 -0400 Date: Mon, 27 Apr 2015 15:29:35 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Lukasz Skalski cc: Greg Kroah-Hartman , Havoc Pennington , Andy Lutomirski , Linus Torvalds , 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 In-Reply-To: <553DFA09.9000605@samsung.com> Message-ID: References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> <553A547A.1060505@samsung.com> <20150424192546.GA13543@kroah.com> <553DFA09.9000605@samsung.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3062 Lines: 72 On Mon, 27 Apr 2015, Lukasz Skalski wrote: > Subject: Re: [GIT PULL] kdbus for 4.1-rc1 > > On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote: >> On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote: >>> On 04/24/2015 04:19 PM, Havoc Pennington wrote: >>>> On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski wrote: >>>>> - client: http://fpaste.org/215156/ >>>>> >>>> >>>> Cool - it might also be interesting to try this without blocking round >>>> trips, i.e. send requests as quickly as you can, and collect replies >>>> asynchronously. That's how people ideally use dbus. It should >>>> certainly reduce the total benchmark time, but just wondering if this >>>> usage increases or decreases the delta between userspace daemon and >>>> kdbus. >>> >>> No problem - I'll prepare also asynchronous version. >> >> That would be great to see as well. Many thanks for doing this work. > > As it was proposed by Havoc and Greg I've created simple benchmark for > asynchronous calls: > > - server: http://fpaste.org/215157/ (the same as in the previous test) > - client: http://fpaste.org/215724/ (asynchronous version) > > For asynchronous version of client I had to decrease number of calls to > 128 (for synchronous version it was x20000 calls), otherwise we can > exceed the maximum number of pending replies per connection. aren't we being told that part of the reason for needing kdbus is that thousands, or tens of thousands of messages are being spewed out? how does limiting it to 128 messages represent real-life if this is the case? David Lang > The test results are following: > > +--------------+--------------------+--------------------+ > | | Elapsed time | Elapsed time | > | Message size | GLIB WITH NATIVE | GLIB + DBUS-DAEMON | > | [bytes] | KDBUS SUPPORT* | | > +--------------+--------------------+--------------------+ > | | 1) 0.018639 s | 1) 0.029947 s | > | 1000 | 2) 0.017045 s | 2) 0.032812 s | > | | 3) 0.017490 s | 3) 0.029971 s | > | | 4) 0.018001 s | 4) 0.026485 s | > +--------------+--------------------+--------------------+ > | | 3) 0.019898 s | 3) 0.040914 s | > | 10000 | 3) 0.022187 s | 3) 0.033604 s | > | | 3) 0.020854 s | 3) 0.037616 s | > | | 3) 0.020020 s | 3) 0.033772 s | > +--------------+--------------------+--------------------+ > *all tests performed without using memfd mechanism. > > And as I wrote in my previous mail, kdbus transport for GLib is not > finished yet and there are still some places for improvements, so please > do not treat these test results as final). > >> >> greg k-h >> > > Cheers, > -- 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/