From: kristof@sigsegv.be (Kristof Provost)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Help learning from my mistakes
Date: Sun, 5 Apr 2015 21:05:18 +0200 [thread overview]
Message-ID: <20150405190518.GN73237@vega.codepro.be> (raw)
In-Reply-To: <81BA72E8-5B31-4AC6-96D7-7B122ED03544@gmail.com>
On 2015-04-05 14:45:28 (-0400), Nicholas Krause <xerofoify@gmail.com> wrote:
>
>
> On April 5, 2015 8:29:47 AM EDT, Kristof Provost <kristof@sigsegv.be> wrote:
> >On 2015-04-05 01:15:31 (-0400), Valdis.Kletnieks at vt.edu
> ><Valdis.Kletnieks@vt.edu> wrote:
> >> On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
> >> > are now slower by up to 3 times,
> >>
> >> So what debugging did you already do to try to narrow this down?
> >>
> >While we're on the subject, let me indulge a pet peeve: How did you
> >measure this? Can you reproduce the measurement? Is the difference
> >statistically significant? What aspect of performance is worse? Task
> >switching time? IO throughput?
> >
> >Benchmarking is *hard*, and 'up to 3 times' is not the result of a
> >careful, well thought out benchmark.
> >
> I ran the make command on all of my CPU cores and timed it. Furthermore it seems to be slower up to 3 times then my distribution kernel based off 3.16.
So, in other words, no, you've not done a careful benchmark at all.
What's the standard deviation on both measurements? How confident are
you (your answer should be a number) that there is a difference?
How have you accounted for VFS cache effects? Have you ensured that both
builds were from a completely clean tree? How have you ensured that no
other jobs interfered with the build (i.e. cron, user interaction, ...)?
Once you've established that there really is a difference you need to
start isolating contributing factors and figure out what's causing the
difference. Alternatively, you can start trying to figure out which part
of overall system performance has been degraded. That requires actually
understanding how the system works and using inspection tools (top,
iostat, perf, ...) to find out where the performance bottleneck is.
None of that is easy or quick. None of these questions can be answered
in one quick sentence. Certainly your overall answer should include more
information, and demonstrate more thought and effort, than 'I did a
build.'.
Regards,
Kristof
next prev parent reply other threads:[~2015-04-05 19:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-03 21:23 Help learning from my mistakes Nicholas Krause
2015-04-04 0:13 ` Valdis.Kletnieks at vt.edu
2015-04-04 19:28 ` Nicholas Krause
2015-04-04 19:32 ` Robert P. J. Day
2015-04-04 19:35 ` Nicholas Krause
2015-04-04 22:53 ` Valdis.Kletnieks at vt.edu
2015-04-04 23:00 ` Nicholas Krause
2015-04-05 5:15 ` Valdis.Kletnieks at vt.edu
2015-04-05 12:29 ` Kristof Provost
2015-04-05 18:45 ` Nicholas Krause
2015-04-05 19:05 ` Kristof Provost [this message]
2015-04-05 19:15 ` Nicholas Krause
2015-04-05 19:26 ` Kristof Provost
2015-04-05 19:30 ` Nicholas Krause
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=20150405190518.GN73237@vega.codepro.be \
--to=kristof@sigsegv.be \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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;
as well as URLs for NNTP newsgroup(s).