Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966116AbbD1Una (ORCPT ); Tue, 28 Apr 2015 16:43:30 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:35865 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965916AbbD1UnZ (ORCPT ); Tue, 28 Apr 2015 16:43:25 -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: Tue, 28 Apr 2015 13:43:24 -0700 X-Google-Sender-Auth: b9agQmEEjn0-MoYyu6zk4C0oefM Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: Linus Torvalds To: Havoc Pennington Cc: David Lang , 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 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: 2223 Lines: 49 On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington wrote: > > From what I can tell, the core performance claim for kdbus is that for > a userspace daemon to be a routing intermediary, it has to receive and > re-send messages. If the baseline performance of IPC is the cost to > send once and receive once, adding the daemon means there's twice as > much to do (1 more receive, 1 more send). However fast you make > send/receive, the daemon always means there are twice as many > send/receives as there would be with no daemon. HOWEVER. That's only a good optimization strategy if the code is optimized to begin with. If the code spends 10x as much time in user space in "overhead" as it actually spends in the kernel, the proper place to optimize is to get rid of the 10x. That will make things much faster. Once user space is lean and mean, at that point do I believe that "ok, let's add kernel code for the last bit of performance". But as it is right now, anybody who works on kdbus and claims that _performance_ is the reason for their work is just looking at teh wrong piece of the puzzle. Now, there may be *other* reasons why kdbus is a good idea. But quite frankly, every time somebody asks "why", performance seems to be one of the main answers. And quite frankly, that *stinks*. Do proper optimizations of the actual real costs before starting to work on kernel stuff. It's *stupid* to add a kernel driver to get 2x improvement, when there's a 10x bloat in user space. Is that really so hard to see? I don't think it is at *all* appropriate to say "we're a f*cking bloated pig, but we're too lazy to fix the bloat and the primary performance problems, so we'll add a kernel interface to partially hide the issue". That is particularly true because if you fix the user-level performance problems, you may notice that there was something stupid in the interfaces, and some of the kernel interface design was wrong. 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/