From: Theodore Ts'o <tytso@mit.edu>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: linux-mips@linux-mips.org,
"Andrea Gelmini" <andrea.gelmini@gelma.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Leonid Yegoshin" <Leonid.Yegoshin@imgtec.com>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
"Matt Redfearn" <matt.redfearn@imgtec.com>,
"Paul Burton" <paul.burton@imgtec.com>,
"Paul Gortmaker" <paul.gortmaker@windriver.com>,
"Ralf Bächle" <ralf@linux-mips.org>,
"Zubair Lutfullah Kakakhel" <Zubair.Kakakhel@imgtec.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: MIPS/kernel/r2-to-r6-emul: Use seq_puts() in mipsr2_stats_show()
Date: Mon, 24 Oct 2016 14:20:38 +0000 [thread overview]
Message-ID: <20161024142037.rrslfxtimj44s5t6@thunk.org> (raw)
In-Reply-To: <e7ac4cba-bce1-edf5-a537-4c06a357bfb3@users.sourceforge.net>
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
next prev parent reply other threads:[~2016-10-24 14:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 12:26 [PATCH 0/4] MIPS-kernel: Fine-tuning for two function implementations SF Markus Elfring
2016-10-24 12:27 ` [PATCH 1/4] MIPS/kernel/r2-to-r6-emul: Use seq_puts() in mipsr2_stats_show() SF Markus Elfring
2016-10-24 13:13 ` Theodore Ts'o
2016-10-24 14:02 ` SF Markus Elfring
2016-10-24 14:20 ` Theodore Ts'o [this message]
2016-10-24 14:53 ` SF Markus Elfring
2016-10-24 15:51 ` Theodore Ts'o
2016-10-24 18:10 ` Further software improvements around Linux sequence API? SF Markus Elfring
2016-10-24 12:28 ` [PATCH 2/4] MIPS/kernel/proc: Use seq_putc() in show_cpuinfo() SF Markus Elfring
2016-10-24 12:29 ` [PATCH 3/4] MIPS/kernel/proc: Replace 28 seq_printf() calls by seq_puts() " SF Markus Elfring
2016-10-24 12:30 ` [PATCH 4/4] MIPS/kernel/proc: Combine four seq_printf() calls into one call " SF Markus Elfring
2016-10-25 8:55 ` Geert Uytterhoeven
2016-10-25 9:08 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161024142037.rrslfxtimj44s5t6@thunk.org \
--to=tytso@mit.edu \
--cc=Leonid.Yegoshin@imgtec.com \
--cc=Zubair.Kakakhel@imgtec.com \
--cc=akpm@linux-foundation.org \
--cc=andrea.gelmini@gelma.net \
--cc=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=matt.redfearn@imgtec.com \
--cc=paul.burton@imgtec.com \
--cc=paul.gortmaker@windriver.com \
--cc=ralf@linux-mips.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox