lkml.org 
[lkml]   [2015]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v4 00/14] Add kdbus implementation
    From
    Hi

    On Thu, Mar 19, 2015 at 4:48 PM, Andy Lutomirski <luto@amacapital.net> wrote:
    > On Thu, Mar 19, 2015 at 4:26 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
    >> metadata handling is local to the connection that sends the message.
    >> It does not affect the overall performance of other bus operations in
    >> parallel.
    >
    > Sure it does if it writes to shared cachelines. Given that you're
    > incrementing refcounts, I'm reasonable sure that you're touching lots
    > of shared cachelines.

    Ok, sure, but it's still mostly local to the sending task. We take
    locks and ref-counts on the task-struct and mm, which is for most
    parts local to the CPU the task runs on. But this is inherent to
    accessing this kind of data, which is the fundamental difference in
    our views here, as seen below..

    >> Furthermore, it's way faster than collecting the "same" data
    >> via /proc, so I don't think it slows down the overall transaction at
    >> all. If a receiver doesn't want metadata, it should not request it (by
    >> setting the receiver-metadata-mask). If a sender doesn't like the
    >> overhead, it should not send the metadata (by setting the
    >> sender-metadata-mask). Only if both peers set the metadata mask, it
    >> will be transmitted.
    >
    > But you're comparing to the wrong thing, IMO. Of course it's much
    > faster than /proc hackery, but it's probably much slower to do the
    > metadata operation once per message than to do it when you connect to
    > the endpoint. (Gah! It's a "bus" that could easily have tons of
    > users but a single "endpoint". I'm still not used to it.)

    Yes, of course your assumption is right if you compare against
    per-connection caches, instead of per-message metadata. But we do
    support _both_ use-cases, so we don't impose any policy.
    We still believe "live"-metadata is a crucial feature of kdbus,
    despite the known performance penalties.

    Thanks
    David


    \
     
     \ /
      Last update: 2015-03-23 16:41    [W:3.050 / U:0.212 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site