[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUaSgdaq4_mr3GG-ekLwGXkQR5MoRLSj9Wu2dTXDYUp1g@mail.gmail.com>
Date: Wed, 5 Aug 2015 13:11:14 -0700
From: Andy Lutomirski <luto@...capital.net>
To: David Herrmann <dh.herrmann@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Djalal Harouni <tixxdz@...ndz.org>,
Greg KH <gregkh@...uxfoundation.org>,
Havoc Pennington <havoc.pennington@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>,
"Kalle A. Sandstrom" <ksandstr@....fi>,
Borislav Petkov <bp@...en8.de>, cee1 <fykcee1@...il.com>
Subject: Re: kdbus: to merge or not to merge?
On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann <dh.herrmann@...il.com> wrote:
> Hi
>
> On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski <luto@...capital.net> wrote:
>> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <dh.herrmann@...il.com> 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 <dh.herrmann@...il.com>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists