Re: kdbus: to merge or not to merge?

[Andy Lutomirski]

On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack <daniel@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/