[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2500336-5848-66c3-ecf0-1ade04decf75@suse.de>
Date: Mon, 17 Oct 2016 11:50:34 +0200
From: Hannes Reinecke <hare@...e.de>
To: SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc: linux-raid@...r.kernel.org, Christoph Hellwig <hch@....de>,
Guoqing Jiang <gqjiang@...e.com>, Jens Axboe <axboe@...com>,
Joe Perches <coupons@...ches.com>,
Mike Christie <mchristi@...hat.com>,
Neil Brown <neilb@...e.com>, Shaohua Li <shli@...nel.org>,
Tomasz Majchrzak <tomasz.majchrzak@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org, kbuild-all@...org,
ltp@...ts.linux.it
Subject: Re: MD-RAID: Use seq_putc() in three status functions?
On 10/17/2016 11:00 AM, SF Markus Elfring wrote:
>>> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
>>> 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.
>
>> 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.
>
>>> 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 …
>
>
>> 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?
>
>
>> 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@...e.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)
Powered by blists - more mailing lists