Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756106AbbHFSn0 (ORCPT ); Thu, 6 Aug 2015 14:43:26 -0400 Received: from mail-la0-f49.google.com ([209.85.215.49]:35789 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755624AbbHFSnZ (ORCPT ); Thu, 6 Aug 2015 14:43:25 -0400 MIME-Version: 1.0 In-Reply-To: <55C3A403.8020202@zonque.org> References: <55C3A403.8020202@zonque.org> From: Andy Lutomirski Date: Thu, 6 Aug 2015 11:43:04 -0700 Message-ID: Subject: Re: kdbus: to merge or not to merge? To: Daniel Mack Cc: David Herrmann , Tom Gundersen , "Kalle A. Sandstrom" , Greg KH , Borislav Petkov , One Thousand Gnomes , Havoc Pennington , Djalal Harouni , cee1 , "Eric W. Biederman" , "linux-kernel@vger.kernel.org" , Linus Torvalds 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: 2113 Lines: 47 On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack wrote: > On 08/06/2015 05:21 PM, Andy Lutomirski wrote: >> Maybe gdbus really does use kdbus already, but on >> very brief inspection it looked like it didn't at least on my test VM. > > No, it's not in any released version yet. The patches for that are being > worked on though and look promising. > >> If the client buffers on !EPOLLOUT and has a monster buffer, then >> that's the client's problem. >> >> If every single program has a monster buffer, then it's everyone's >> problem, and the size of the problem gets multiplied by the number of >> programs. > > The size of the memory pool of a bus client is chosen by the client > itself individually during the HELLO call. It's pretty much the same as > if the client allocated the buffer itself, except that the kernel does > it on their behalf. > > Also note that kdbus features a peer-to-peer based quota accounting > logic, so a single bus connection can not DOS another one by filling its > buffer. I haven't looked at the quota code at all. Nonetheless, it looks like the slice logic (aside: it looks *way* more complicated than necessary -- what's wrong with circular buffers) will, under most (but not all!) workloads, concentrate access to a smallish fraction of the pool. This is IMO bad, since it means that most of the time most of the pool will remain uncommitted. If, at some point, something causes the access pattern to change and hit all the pages (even just once), suddenly all of the pools get committed, and your memory usage blows up. Again, please stop blaming the clients. In practice, kdbus is a system involving the kernel, systemd, sd-bus, and other stuff, mostly written by the same people. If kdbus gets merged and it survives but half the clients blow up and peoples' systems fall over, that's not okay. --Andy -- 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/