Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161015AbbHGPh6 (ORCPT ); Fri, 7 Aug 2015 11:37:58 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:32980 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030183AbbHGPhz (ORCPT ); Fri, 7 Aug 2015 11:37:55 -0400 MIME-Version: 1.0 In-Reply-To: References: <55C3A403.8020202@zonque.org> From: cee1 Date: Fri, 7 Aug 2015 23:37:35 +0800 Message-ID: Subject: Re: kdbus: to merge or not to merge? To: "linux-kernel@vger.kernel.org" Cc: Daniel Mack , David Herrmann , Tom Gundersen , "Kalle A. Sandstrom" , Greg KH , Borislav Petkov , One Thousand Gnomes , Havoc Pennington , Djalal Harouni , "Eric W. Biederman" , Linus Torvalds , Andy Lutomirski 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: 3136 Lines: 72 2015-08-07 2:43 GMT+08:00 Andy Lutomirski : > 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. Any comments about the questions mentioned by Andy? In KDBUS, sender writes a page of receiver's tmpfs space, may either helps receiver to escape its memcg limitation, or incurs receiver's limitation? Also, I'm curious about similar problems in these cases: 1. A UNIX domain Server (SOCK_STREAM or SOCK_DGRAM) replies to its Clients, but some clients consume the messages __too slow__, will the server block? Or can it serve other clients instead of blocking? 2. Open netlink sockets of NETLINK_KOBJECT_UEVENT, but some processes consume uevent __too slow__, and uevent is continually triggered. Will the system block? Or those processes finally lost some uevents? 3. Watch a directory via inotify, but some processes consume events __too slow__, and file operations is continually performed against the directory. Will the system block? Or those processes finally lost some events? -- Regards, - cee1 -- 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/