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]

Message-ID: <20161024142037.rrslfxtimj44s5t6@thunk.org>
Date:   Mon, 24 Oct 2016 10:20:38 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     linux-mips@...ux-mips.org,
        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()

On Mon, Oct 24, 2016 at 04:02:49PM +0200, SF Markus Elfring wrote:
> > You should fix this in all the patches.
> I am curious if a second approach will become acceptable in the near
> future.

I don't know what you were asking.  I was merely point out that the
> wording was factually incorrect in all of the patches, and I didn't
> feel like replying five times to point out the same mistake.

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

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.

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.  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.  So trying to send more
useful patches might be more helpful if your goal is to try to get
gainful employment.

Cheers,

						- Ted