On 10/17/2016 11:00 AM, SF Markus Elfring wrote:

quoted

quoted

Calling the function "seq_putc" will be more efficient than "seq_printf"
in this case because of the following reasons.

1. How does the distribution look like for supported processor architectures
   where the data transfer for bytes (as a function call parameter)
   is faster than for (string) pointers?

How would I know?

How many processor architecture characteristics do you know already?

x86, s390x, ppc/ppc64.

* Is a string pointer often longer than a byte?

Always.

(Which up to now I thought was basic programming knowledge...)

* I imagine that it can become also interesting to check byte level data access
  under constraints of machine word sizes and alignment.

So, another test for you to do.

quoted

I would assume that _you_ did some measurements here;

How much would you trust in any concrete numbers I could present
for this use case?

Do you give more trust to a reference testing platform?

At the moment _any_ test would do.
With every response from your side you just keep on asking further
questions. But so far you haven't delivered any answers nor measurements.

quoted

I could easily claim that seq_printf() is more efficient than
seq_putc(), and won't apply your patch.

This is also possible in principle.

No, this is what's going to happen if you don't show any measurements.

quoted

So _you_ have to prove that your patch is more efficient.

How many results would we like to clarify from various hardware
and software combinations?

See above. At the moment _any_ test result from your side would do.

quoted

quoted

2. Did anybody measure already how many the execution times can vary
   for these functions?

Probably not.

Thanks for this information.

How important are the mentioned functions for you within the Linux
programming interface so far?

Not very. The interface is only used in a slow path, and the execution
time doesn't affect I/O performance in any way.

quoted

Unless _you_ prove that _your_ patch is more efficient it won't get applied.

Which data would you accept as a "prove" in this case?

Again: You want something from us. We don't have to prove anything, you
need to convince us. And it is really hard to convince anyone by asking
questions.

quoted

quoted

   Where do you get doubts about its efficiency for the data processing
   of a single character?

Because it's being called at the end of a function calling seq_printf() already.

Interesting view …

quoted

So exchanging a single call is probably not helping anything,
as the compiler will optimize it anyway.

How common is the discussed software transformation between implementations
for optimising compilers?

quoted

Case in point: with your patch the x86_64 compiler generates nearly
identical code for driver/md/raid1.c, but with one instruction _more_
after your patch has been applied.

Which software versions and command parameters did you try out
for this information (from an unspecified run time environment)?

# gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

git tree from git.kernel.org/mkp/u/4.10/scsi-queue

_I_ did some measurements.
I'm still waiting from results from your side.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)