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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 17 Oct 2016 09:39:25 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Hannes Reinecke <hare@...e.de>
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?

>>> 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?

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

3. seq_printf() provides more functionality as this kind of programming
   interface was designed for a bigger purpose.
   How much do you care for consequences when such general functions
   are called with input data they were not designed for mainly?

4. The seq_putc() implementation is so simple.
   http://lxr.free-electrons.com/source/fs/seq_file.c?v=4.8#L657

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

> It's your patch, after all.

Yes. - I published a special update suggestion once again.

> Once you do (and prove that the answer is 'yes' to the above two
> questions) the patch will be applied.

How do you think about to share a bit more from your software development
and testing experience?
Which call frequencies do you observe for the affected functions?

1. raid1_status
2. raid10_status
3. raid5_status

Regards,
Markus