From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Paul Mackerras <paulus@samba.org>,
Stephane Eranian <eranian@google.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Zhang Yanmin <yanmin_zhang@linux.intel.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 0/5] perf events finer grained context instrumentation / context exclusion
Date: Thu, 10 Jun 2010 19:03:42 +0200 [thread overview]
Message-ID: <20100610170340.GF5255@nowhere> (raw)
In-Reply-To: <20100610101637.GA10406@elte.hu>
On Thu, Jun 10, 2010 at 12:16:37PM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > Performance counter stats for './hackbench 5' (10 runs):
> >
> > 1313640764 instructions # 0,241 IPC ( +- 1,393% ) (scaled from 100,05%)
> > 214737441 branches ( +- 0,948% )
> >
> > 1293802776 instructions # 0,245 IPC ( +- 0,343% )
> > 209495435 branches ( +- 0,392% )
>
> Indeed it's about 4 times less noise, not bad.
>
> Cycles is fundamentally random.
>
> > So yeah, the results look a bit better. Still not perfects:
> >
> > - we are still instrumenting the tiny parts between the true interrupt
> > and irq_enter() (same for irq_exit() and the end). Same for softirqs.
> >
> > - random randomnesses...
>
> Random randomness shouldnt occur for something like instructions or branches.
>
> Could you try some 'must not be variable' workload, like:
>
> taskset 1 ./hackbench 1
>
> If the workload is pinned to a single CPU then it ought to not be variable at
> all. (modulo things like hash chain lengths and slab caching details, but
> those should not cause 0.4% kind of noise IMO)
Good idea, with that we have at least less variations between profiles.
Now the results:
$ sudo ./perf stat -e instructions -e cycles -e branches -e branch-misses -v -r 10 taskset 1 ./hackbench 1
Performance counter stats for 'taskset 1 ./hackbench 1' (10 runs):
318090069 instructions # 0,371 IPC ( +- 2,238% )
856426449 cycles ( +- 2,207% )
51704292 branches ( +- 2,264% )
2321798 branch-misses # 4,491 % ( +- 2,815% )
0,541982879 seconds time elapsed ( +- 2,185% )
$ sudo ./perf stat -e instructions:t -e cycles:t -e branches:t -e branch-misses:t -v -r 10 taskset 1 ./hackbench 1
Performance counter stats for 'taskset 1 ./hackbench 1' (10 runs):
305852952 instructions # 0,371 IPC ( +- 1,775% )
823521707 cycles ( +- 1,753% )
49712722 branches ( +- 1,801% )
2210546 branch-misses # 4,447 % ( +- 2,219% )
0,538258337 seconds time elapsed ( +- 1,737% )
I did the same tests by deactivating my secondary cpu (to deactivate SMT)
but there the result were about the same between :t and non :t
>
> Btw., we could try to record all branches of an execution (using BTS, of a
> relatively short but static-length run), and see where the variance comes
> from. I doubt the current BTS code is ready for that, but it would be 'the'
> magic trace-from-hell that includes all execution of the task, recorded at the
> hardware level.
Agreed, we could cook a nice diff graph about this.
prev parent reply other threads:[~2010-06-10 17:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 3:49 [PATCH 0/5] perf events finer grained context instrumentation / context exclusion Frederic Weisbecker
2010-06-10 3:49 ` [PATCH 1/5] perf: Provide a proper stop action for software events Frederic Weisbecker
2010-06-10 10:46 ` Peter Zijlstra
2010-06-10 11:10 ` Peter Zijlstra
2010-06-10 16:12 ` Frederic Weisbecker
2010-06-10 16:16 ` Peter Zijlstra
2010-06-10 16:29 ` Frederic Weisbecker
2010-06-10 16:38 ` Peter Zijlstra
2010-06-10 17:04 ` Frederic Weisbecker
2010-06-10 19:54 ` Frederic Weisbecker
2010-06-10 12:06 ` Ingo Molnar
2010-06-10 3:49 ` [PATCH 2/5] perf: Support disable() after stop() on " Frederic Weisbecker
2010-06-10 10:50 ` Peter Zijlstra
2010-06-10 16:31 ` Frederic Weisbecker
2010-06-10 3:49 ` [PATCH 3/5] perf: New PERF_EVENT_STATE_PAUSED event state Frederic Weisbecker
2010-06-10 10:55 ` Peter Zijlstra
2010-06-10 16:26 ` Frederic Weisbecker
2010-06-10 3:49 ` [PATCH 4/5] perf: Introduce task, softirq and hardirq contexts exclusion Frederic Weisbecker
2010-06-10 11:01 ` Peter Zijlstra
2010-06-10 16:24 ` Frederic Weisbecker
2010-06-10 3:49 ` [PATCH 5/5] perf: Support for task/softirq/hardirq exclusion on tools Frederic Weisbecker
2010-06-10 6:26 ` [PATCH 0/5] perf events finer grained context instrumentation / context exclusion Ingo Molnar
2010-06-10 7:15 ` Frederic Weisbecker
2010-06-10 7:31 ` Frederic Weisbecker
2010-06-10 10:16 ` Ingo Molnar
2010-06-10 17:03 ` Frederic Weisbecker [this message]
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=20100610170340.GF5255@nowhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=yanmin_zhang@linux.intel.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.