mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	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: [PATCH 0/5 v3] perf events finer grained context instrumentation / context exclusion
Date: Sat, 12 Jun 2010 09:34:53 +0200	[thread overview]
Message-ID: <1276328098-24114-1-git-send-regression-fweisbec@gmail.com> (raw)

Hi,

In this new version, the weird hangs have been fixed. They were
due to some ACTIVE state checks that didn't handle the paused
mode.

And also comes a new pmu->reserve callback to schedule an event
on the cpu without actually starting it (as if ->stop() was
just called in it).
In x86 it is the same than the enable() callback, the decision
to activate the event beeing eventually handled by checking the
PERF_EVENT_STATE_PAUSED. On software events it is a stub as
they can be activated anytime in a lightweight fashion, without
the need to fight against a finite resource.

BTW, there is a quite handy way to make a diff between task
context and task + irq context profiling.

Just run:

sudo ./perf stat -r 10 -e task-clock -e task-clock:t -e cs -e cs:t \
	-e migrations -e migrations:t -e faults -e faults:t -e cycles \
	-e cycles:t -e instructions -e instructions:t -e branches \
	-e branches:t -e branch-misses -e branch-misses:t taskset 1 hackbench 1

(Did I just say handy?)

Example of result:

 Performance counter stats for 'taskset 1 hackbench 1' (10 runs):

         604,727182  task-clock-msecs         #      0,969 CPUs    ( +-   6,176% )
         604,727182  task-clock-msecs         #      0,969 CPUs    ( +-   6,176% )
              11584  context-switches         #      0,019 M/sec   ( +-  26,945% )
              11593  context-switches         #      0,019 M/sec   ( +-  26,909% )
                  1  CPU-migrations           #      0,000 M/sec   ( +-  61,464% )
                  0  CPU-migrations           #      0,000 M/sec   ( +- 100,000% )
               1844  page-faults              #      0,003 M/sec   ( +-   1,425% )
               1847  page-faults              #      0,003 M/sec   ( +-   1,423% )
          917442262  cycles                   #   1517,118 M/sec   ( +-   6,814% )  (scaled from 69,40%)
          908980892  cycles                   #   1503,126 M/sec   ( +-   5,807% )  (scaled from 68,51%)
          335812687  instructions             #      0,368 IPC     ( +-   6,977% )  (scaled from 73,77%)
          321284628  instructions             #      0,352 IPC     ( +-   6,377% )  (scaled from 20,59%)
           48956776  branches                 #     80,957 M/sec   ( +-   5,936% )  (scaled from 22,67%)
           48144741  branches                 #     79,614 M/sec   ( +-   6,480% )  (scaled from 21,68%)
            2310259  branch-misses            #      4,758 %       ( +-   9,698% )  (scaled from 15,11%)
            2200507  branch-misses            #      4,532 %       ( +-   9,294% )  (scaled from 15,35%)

        0,624082951  seconds time elapsed   ( +-   5,939% )


Most of the time, the instruction counter diff shows that irqs take 0.01% of noise
with hackbench. Something that does more IO would probably be a more
interesting example.

The thing is pullable there:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	perf/exclusion-4

Thanks.


Frederic Weisbecker (5):
  perf: Provide a proper stop action for software events
  perf: Support disable() after stop() on software events
  perf: Ability to enable in a paused mode
  perf: Introduce task, softirq and hardirq contexts exclusion
  perf: Support for task/softirq/hardirq exclusion on tools

 arch/x86/kernel/cpu/perf_event.c |    7 +-
 include/linux/perf_event.h       |   52 ++++++++-
 kernel/hw_breakpoint.c           |    1 +
 kernel/perf_event.c              |  257 +++++++++++++++++++++++++++++++-------
 kernel/softirq.c                 |    6 +
 kernel/trace/trace_event_perf.c  |    2 +-
 tools/perf/util/parse-events.c   |   37 ++++--
 7 files changed, 302 insertions(+), 60 deletions(-)


             reply	other threads:[~2010-06-12  7:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-12  7:34 Frederic Weisbecker [this message]
2010-06-12  7:34 ` [PATCH 1/5] perf: Provide a proper stop action for software events Frederic Weisbecker
2010-06-12  9:43   ` Peter Zijlstra
2010-06-12 16:25     ` Frederic Weisbecker
2010-06-12  7:34 ` [PATCH 2/5] perf: Support disable() after stop() on " Frederic Weisbecker
2010-06-12  7:34 ` [PATCH 3/5] perf: Ability to enable in a paused mode Frederic Weisbecker
2010-06-12  9:44   ` Peter Zijlstra
2010-06-12 16:44     ` Frederic Weisbecker
2010-06-12  7:34 ` [PATCH 4/5] perf: Introduce task, softirq and hardirq contexts exclusion Frederic Weisbecker
2010-06-12  7:34 ` [PATCH 5/5] perf: Support for task/softirq/hardirq exclusion on tools 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=1276328098-24114-1-git-send-regression-fweisbec@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®