linux-kernel - Re: MD-RAID: Use seq_putc() in three status functions?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 Oct 2016 10:09:50 +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
Subject: Re: MD-RAID: Use seq_putc() in three status functions?

On 10/17/2016 09:39 AM, SF Markus Elfring wrote:
>>>> Does it improve code? Does it improve anything?
>>>
>>> Yes. - I got such an impression.
>>>
>>> * Is it more efficient to call the function "seq_printf" for the desired data processing
>>>   for a single character than to pass it to the function "" in a string?
>>>
>>> * Will the required data transfer shrink a bit for the affected functions because of
>>>   such a change?
>>>
>> Which are questions _you_ should be able to answer.
> 
> I wonder that the answers are not obvious for you already.
> 
> 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? I would assume that _you_ did some measurements here;
after all, _you_ are trying to push this patch.
I could easily claim that seq_printf() is more efficient than
seq_putc(), and won't apply your patch.
So _you_ have to prove that your patch is more efficient.

> 2. Did anybody measure already how many the execution times can vary
>    for these functions?
> 
Probably not.
But referring to the previous topic:
Unless _you_ prove that _your_ patch is more efficient it won't get
applied. _You_ want us to apply your patch, so the burden is on _you_ to
provide the required data.


>    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. So exchanging a single call is probably not helping anything,
as the compiler will optimize it anyway.
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.

So it's not immediately obvious that your patch is an improvement.

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)