All of lore.kernel.org
 help / color / mirror / Atom feed
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.


      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.