linux-kernel - Re: MIPS/kernel/r2-to-r6-emul: Use seq_puts() in mipsr2_stats

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, 24 Oct 2016 16:53:32 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Theodore Ts'o <tytso@....edu>, linux-mips@...ux-mips.org
Cc:     Andrea Gelmini <andrea.gelmini@...ma.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Matt Redfearn <matt.redfearn@...tec.com>,
        Paul Burton <paul.burton@...tec.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Ralf Bächle <ralf@...ux-mips.org>,
        Zubair Lutfullah Kakakhel <Zubair.Kakakhel@...tec.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: MIPS/kernel/r2-to-r6-emul: Use seq_puts() in mipsr2_stats_show()

>> I am curious if a second approach will become acceptable in the near future.
> 
> I don't know what you were asking.

I am trying to clarify the suggested software evolution again.


> I was merely point out that the wording was factually incorrect
> in all of the patches,

Thanks for this information.


> and I didn't feel like replying five times to point out the same mistake.

This is fine.


>>> since reading from /proc isn't done in a tight loop, and even if it were,
>>> the use of vsprintf is the tiniest part of the overhead.
>>
>> Thanks for your software development opinion.
> 
> It's a lot more than just an opinion.  I challenge you to demonstrate
> how much savings it would take.  Try learning how to use another tool
> --- say, perf.  Measure how many clock cycles it takes to read from a
> proc file that uses seq_printf().  Then measure how many clock cycles
> it takes to read from a proc file that uses seq_puts().  Try doing the
> experiment 3-5 times each way, to see if the difference is within
> measurement error, and then figure out what percentage of the total
> CPU time you have saved.

Are there any more software developers interested in such system
performance analyses?


> If this sort of thing appeals to you, you might want to consider a
> more productive line of work.  For example, you could do scalability
> measurements.  Run various benchmarks with lockdep enabled, and
> measure the average and max hold time on various locks.  Now see if
> you can reduce the max hold time on those locks.  You may find that
> you can improve performance for real work loads by orders of magnitude
> more than you can by sending the sorts of patches you've sent up until now.

Thanks for your hints around other software development areas.


> You'd also development more marketable kernel skills, if that has been
> your goal by spamming the list with hundreds and thousands of mostly
> pointless patches.

You might categorise my update suggestions with a low value so far.


> Note that if a hiring manager were to talk to developers and get
> their opinion of the sorts of patches you have been sending, trust me,
> it would _not_ be positive.

There are also some constraints around change resistance involved,
aren't there?

* Do my suggestions show small improvements for Linux source files?

* If you find some of them so awful, why should I attempt to improve
  any commit messages in another patch series then?


> So trying to send more useful patches might be more helpful
> if your goal is to try to get gainful employment.

Financial incentives would be also nice as you seem to indicate here.

Regards,
Markus