Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753601AbbHEULi (ORCPT ); Wed, 5 Aug 2015 16:11:38 -0400 Received: from mail-lb0-f175.google.com ([209.85.217.175]:35800 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbbHEULg (ORCPT ); Wed, 5 Aug 2015 16:11:36 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Wed, 5 Aug 2015 13:11:14 -0700 Message-ID: Subject: Re: kdbus: to merge or not to merge? To: David Herrmann Cc: Linus Torvalds , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack , "Kalle A. Sandstrom" , Borislav Petkov , cee1 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: 2875 Lines: 74 On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann wrote: > Hi > > On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski wrote: >> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote: >>> This is a bug in the proxy (which is already fixed). >> >> Should I expect to see it in Rawhide soon? > > Use this workaround until it does: > > $ DBUS_SYSTEM_BUS_ADDRESS="kernel:path=/sys/fs/kdbus/0-system/bus" > ./your-binary > Which binary is supposed to be run like that? >> Anyway, the broadcasts that I intended to exercise were >> KDBUS_ITEM_ID_REMOVE. Those appear to be broadcast to everyone, >> irrespective of "policy", so long as the "match" thingy allows it. > > Matches are opt-in, not opt-out. Nobody will get this message unless > they opt in. > And what opts in? Either something's broken, or there's a different scalabilty problem, or a whole pile of kdbus-using programs in Fedora Rawhide do, in fact, opt in. My interest in instrumenting kdbus and systemd to figure out the exact mechanism by which my tiny test case causes my system to freeze is near zero. I bet I'm actually right about the mechanism, but that's sort of beside the point. It freezes, so /something's/ wrong. The only real relevance of my suspicion about the failure mode is that I think it's a design issue that isn't going to be easy to fix. > >> So yes, as far as I can tell, kdbus really does track object lifetime >> by broadcasting every single destruction event to every single >> receiver (subject to caveats above) and pokes the data into every >> receiver's tmpfs space. > > Broadcast reception is opt-in. I've pointed out several times that there a feature in kdbus that doesn't work well and I get told that the problematic feature is opt-in. Given that all existing prototype userspace that I'm aware of (systemd and its consumers) apparently opts in, I don't really care that the feature is opt-in. Also, given things like this: commit d27c8057699d164648b7d8c1559fa6529998f89d Author: David Herrmann Date: Tue May 26 09:30:14 2015 +0200 kdbus: forward ID notifications to everyone it really does seem to me that the point of these ID notifications is for everyone to get them. Also, you haven't addressed the memory usage issues -- I don't see how a full kdbus-using desktop system can be expected to fit into RAM on anything short of the biggest and beefiest laptops. I also don't see how a kdbus-using xdg-app-happy kdbus-using system (with correspondingly many pools) will fit into RAM on even the biggest laptops. --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/