All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	Thomas Richter <tmricht@linux.ibm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] Perf stat --null/offline CPU segv related fixes/tests
Date: Tue, 9 Dec 2025 09:44:45 +0100	[thread overview]
Message-ID: <aTfhfVywjweJyCHw@gmail.com> (raw)
In-Reply-To: <CAP-5=fURCzNLC8izLAbu50AV7nhLmCDwaDpfiWkQp3ihgHMNxg@mail.gmail.com>


* Ian Rogers <irogers@google.com> wrote:

> > There's one more perf stat QoL bug I'd like to report - I frequently
> > do repeated runs of perf stat --repeat and grep the output, to get
> > a feel for the run-to-run stability of a particular benchmark:
> >
> >   starship:~/tip> while :; do perf stat --null --repeat 3 sleep 0.1 2>&1 | grep elapsed; done
> >          0.1017997 +- 0.0000771 seconds time elapsed  ( +-  0.08% )
> >          0.1017627 +- 0.0000795 seconds time elapsed  ( +-  0.08% )
> >          0.1018106 +- 0.0000650 seconds time elapsed  ( +-  0.06% )
> >          0.1017844 +- 0.0000601 seconds time elapsed  ( +-  0.06% )
> >           0.101883 +- 0.000169 seconds time elapsed  ( +-  0.17% ) <====
> >          0.1017757 +- 0.0000532 seconds time elapsed  ( +-  0.05% )
> >          0.1017991 +- 0.0000720 seconds time elapsed  ( +-  0.07% )
> >          0.1018024 +- 0.0000704 seconds time elapsed  ( +-  0.07% )
> >          0.1018074 +- 0.0000946 seconds time elapsed  ( +-  0.09% )
> >          0.1019797 +- 0.0000524 seconds time elapsed  ( +-  0.05% )
> >          0.1018407 +- 0.0000658 seconds time elapsed  ( +-  0.06% )
> >          0.1017907 +- 0.0000605 seconds time elapsed  ( +-  0.06% )
> >          0.1018328 +- 0.0000868 seconds time elapsed  ( +-  0.09% )
> >          0.1017469 +- 0.0000285 seconds time elapsed  ( +-  0.03% )
> >          0.1019589 +- 0.0000549 seconds time elapsed  ( +-  0.05% )
> >          0.1018465 +- 0.0000891 seconds time elapsed  ( +-  0.09% )
> >           0.101868 +- 0.000117 seconds time elapsed  ( +-  0.12% ) <====
> >          0.1017705 +- 0.0000590 seconds time elapsed  ( +-  0.06% )
> >          0.1017728 +- 0.0000718 seconds time elapsed  ( +-  0.07% )
> >          0.1017821 +- 0.0000419 seconds time elapsed  ( +-  0.04% )
> >          0.1018328 +- 0.0000581 seconds time elapsed  ( +-  0.06% )
> >          0.1017836 +- 0.0000853 seconds time elapsed  ( +-  0.08% )
> >          0.1018124 +- 0.0000765 seconds time elapsed  ( +-  0.08% )
> >          0.1018706 +- 0.0000639 seconds time elapsed  ( +-  0.06% )
> >
> > Note the two outliers, which happen due to some misguided
> > output optimization feature in perf shortening zero-ended
> > numbers unnecessarily, and adding noise to the grepped
> > output's vertical alignment.
> >
> > Those two lines should be:
> >
> >          0.1017844 +- 0.0000601 seconds time elapsed  ( +-  0.06% )
> >          0.1018830 +- 0.0001690 seconds time elapsed  ( +-  0.17% ) <====
> >          0.1017757 +- 0.0000532 seconds time elapsed  ( +-  0.05% )
> >
> >          0.1018465 +- 0.0000891 seconds time elapsed  ( +-  0.09% )
> >          0.1018680 +- 0.0001170 seconds time elapsed  ( +-  0.12% ) <====
> >          0.1017705 +- 0.0000590 seconds time elapsed  ( +-  0.06% )
> >
> > (The zeroes are printed fully, to full precision.)
> >
> > Basically random chance causing an apparent lack of significant
> > numbers doesn't mean the tool should strip them from the output.
>
> Ugh. I'm not sure why the output is like that.

Yeah, I'm sure some dim-witted kernel developer requested it,
without thinking through all the consequences.

> [...] Searching back through history it seems you are to blame :-)
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/tools/perf/builtin-stat.c?h=perf-tools-next&id=bc22de9bcdb2249150fb5b3c48fdc4f6bedd3ad7

Uhm, never mind, what a brilliant feature! ;-)

> Perhaps we can drop the precision printf flag and just make the flags
> fixed. I think this output is obscure enough that nobody cares about
> minor changes.

Yeah, sounds good.

Thanks,

	Ingo


  reply	other threads:[~2025-12-09  8:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03 21:46 [PATCH v2 0/7] Perf stat --null/offline CPU segv related fixes/tests Ian Rogers
2025-12-03 21:47 ` [PATCH v2 1/7] perf stat: Allow no events to open if this is a "--null" run Ian Rogers
2025-12-03 21:47 ` [PATCH v2 2/7] libperf cpumap: Fix perf_cpu_map__max for an empty/NULL map Ian Rogers
2025-12-03 21:47 ` [PATCH v2 3/7] perf cpumap: Add "any" CPU handling to cpu_map__snprint_mask Ian Rogers
2025-12-03 21:47 ` [PATCH v2 4/7] perf tests stat: Add "--null" coverage Ian Rogers
2025-12-03 21:47 ` [PATCH v2 5/7] perf stat: When no events, don't report an error if there is none Ian Rogers
2025-12-03 21:47 ` [PATCH v2 6/7] perf tests stat: Add test for error for an offline CPU Ian Rogers
2025-12-03 21:47 ` [PATCH v2 7/7] perf stat: Improve handling of termination by signal Ian Rogers
2025-12-04  7:51 ` [PATCH v2 0/7] Perf stat --null/offline CPU segv related fixes/tests Thomas Richter
2025-12-04 19:10 ` Namhyung Kim
2025-12-06  9:35 ` Ingo Molnar
2025-12-06 11:20   ` Ingo Molnar
2025-12-07  1:43     ` Ian Rogers
2025-12-09  8:44       ` Ingo Molnar [this message]
2025-12-09 17:38         ` Ian Rogers

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=aTfhfVywjweJyCHw@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tmricht@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.