On 06/25/2014 06:56 PM, Daniel Mack wrote:
Hi,

On 06/25/2014 11:13 AM, AKASHI Takahiro wrote:
My ftrace log shows that kdbus_meta_append(), is one of dominant functions
in sending a message, while the other is kdbus_conn_queue_alloc().
This patch adds an extra argument to kdbus_hello() utility function and
allows us to explicitly specify meta information attached to a message
for performance evaluation.

Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
  test/kdbus-util.c |   35 +++++++++++++++++++++--------------
  test/kdbus-util.h |    2 ++
  2 files changed, 23 insertions(+), 14 deletions(-)

Note that the kernel features of kdbus are defined by the kernel code,
not by the convenience wrappers for ioctl() that live in test/. As soon
as you start to implement your own code using kdbus features, I'd
strongly recommend you start over and implement your own low-level
functions. The ioctl API is actually simple enough to do this.

This patch in my patchset might have misguided you.
I know that the existing ioctl has a feature of customizing meta information
attached to a message. What this patch does is just to modify a test utility 
function,
kdbus_hello(), temporarily to see the performance differences with and without
meta info.

I never say that meta info is meaningless, but
I would like people to be more careful about it not only because choosing an 
appropriate set
of meta info does make sense, but also because it has quit big impact on 
latency.

The original test/test-kdbus-benchmark also uses kdbus_hello(), and so the 
performance can
look worse. (In other words, the worst case numbers?)

Assuming that attaching meta is necessary but its also expensive, it might be a 
good idea
to have and check meta info not per message, but per connection. (In this case, 
we may have to
invent higher-level protocol/concept).

What do you think of that?

Thanks,
-Takahiro AKASHI


Same counts for patch #2 and #3 of this series.


Thanks,
Daniel

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to