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 09:31:42 +0200	[thread overview]
Message-ID: <20100610073140.GE12752@nowhere> (raw)
In-Reply-To: <20100610062618.GA20062@elte.hu>

On Thu, Jun 10, 2010 at 08:26:18AM +0200, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > Here is the new version of per context exclusion, based on hooks on 
> > irq_enter/irq_exit. I haven't observed slowdowns but I haven't actually 
> > measured the impact.
> 
> One thing that would be nice to see in this discussion is a comparison of 
> before/after perf stat --repeat runs.
> 
> Something like:
> 
>   perf stat --repeat ./hackbench 5
> 
> Done with full stat, and then also done with hardirqs/softirqs excluded. (i.e. 
> task context stats only)
> 
> I.e. does the feature really give us the expected statistical stability in 
> results? Does it really exclude hardirq/softirq workloads, etc.?
> 
> Thanks,
> 
> 	Ingo


Just got some results:

$ sudo ./perf stat -e instructions -e cycles -e branches -e branch-misses -v -r 10 ./hackbench 5

 Performance counter stats for './hackbench 5' (10 runs):

         1313640764  instructions             #      0,241 IPC     ( +-   1,393% )  (scaled from 100,05%)
         5440853130  cycles                     ( +-   0,925% )  (scaled from 100,05%)
          214737441  branches                   ( +-   0,948% )
           12332109  branch-misses            #      5,743 %       ( +-   1,239% )

        1,727051101  seconds time elapsed   ( +-   0,897% )


$ sudo ./perf stat -e instructions:t -e cycles:t -e branches:t -e branch-misses:t -v -r 10 ./hackbench 5

 Performance counter stats for './hackbench 5' (10 runs):

         1293802776  instructions             #      0,245 IPC     ( +-   0,343% )
         5280769301  cycles                     ( +-   0,471% )  (scaled from 100,02%)
          209495435  branches                   ( +-   0,392% )
           11890938  branch-misses            #      5,676 %       ( +-   0,491% )

        1,750534923  seconds time elapsed   ( +-   0,463% )


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


Another try, this time with a kernel downloading in parallel, to generate
network interrupts:


$ sudo ./perf stat -e instructions -e cycles -e branches -e branch-misses -v -r 10 ./hackbench 5

 Performance counter stats for './hackbench 5' (10 runs):

         1324759169  instructions             #      0,244 IPC     ( +-   0,494% )  (scaled from 100,09%)
         5424824320  cycles                     ( +-   0,503% )
          214443106  branches                   ( +-   0,516% )
           12245614  branch-misses            #      5,710 %       ( +-   0,604% )

        1,723413199  seconds time elapsed   ( +-   0,483% )


$ sudo ./perf stat -e instructions:t -e cycles:t -e branches:t -e branch-misses:t -v -r 10 ./hackbench 5

 Performance counter stats for './hackbench 5' (10 runs):

         1292119132  instructions             #      0,251 IPC     ( +-   0,138% )
         5138407131  cycles                     ( +-   2,708% )
          209052068  branches                   ( +-   0,139% )
           11835090  branch-misses            #      5,661 %       ( +-   0,105% )

        1,752192124  seconds time elapsed   ( +-   0,278% )


Again, globally better, except for the cycles this time.


  parent reply	other threads:[~2010-06-10  7:31 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 [this message]
2010-06-10 10:16     ` Ingo Molnar
2010-06-10 17:03       ` Frederic Weisbecker

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=20100610073140.GE12752@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.