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

[SF Markus Elfring <elfring@users.sourceforge.net>]

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