mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Tony Luck <tony.luck@intel.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephane Eranian <eranian@googlemail.com>,
	Eric Dumazet <dada1@cosmosbay.com>,
	Robert Richter <robert.richter@amd.com>,
	Arjan van de Veen <arjan@infradead.org>,
	Peter Anvin <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [patch] Performance Counters for Linux, v3
Date: Thu, 11 Dec 2008 20:34:39 +0100	[thread overview]
Message-ID: <20081211193439.GA25986@elte.hu> (raw)
In-Reply-To: <12c511ca0812111111t2992dd2cw8b4d57ac57bd0700@mail.gmail.com>


* Tony Luck <tony.luck@intel.com> wrote:

> >        /*
> >         * Special "software" counters provided by the kernel, even if
> >         * the hardware does not support performance counters. These
> >         * counters measure various physical and sw events of the
> >         * kernel (and allow the profiling of them as well):
> >         */
> >        PERF_COUNT_CPU_CLOCK            = -1,
> >        PERF_COUNT_TASK_CLOCK           = -2,
> >        /*
> >         * Future software events:
> >         */
> >        /* PERF_COUNT_PAGE_FAULTS       = -3,
> >           PERF_COUNT_CONTEXT_SWITCHES  = -4, */
> 
>   ...
> > +[ Note: more hw_event_types are supported as well, but they are CPU
> > +  specific and are enumerated via /sys on a per CPU basis. Raw hw event
> > +  types can be passed in as negative numbers. For example, to count
> > +  "External bus cycles while bus lock signal asserted" events on Intel
> > +  Core CPUs, pass in a -0x4064 event type value. ]
> 
> It looks like you have an overlap here.  You are using some negative 
> numbers to denote your special software events, but also as "raw" 
> hardware events. What if these conflict?

that's an old comment, not a bug in the code - thx for pointing it out, i 
just fixed the comments - see the commit below.

Raw events are now done without using up negative numbers, they are done 
via:

 struct perf_counter_hw_event {
        s64                     type;

        u64                     irq_period;
        u32                     record_type;

        u32                     disabled     :  1, /* off by default */
                                nmi          :  1, /* NMI sampling   */
                                raw          :  1, /* raw event type */
                                __reserved_1 : 29;

        u64                     __reserved_2;
 };

if the hw_event.raw bit is set to 1, then the hw_event.type is fully 
'raw'. The default is for raw to be 0. So negative numbers can be used 
for sw events, positive numbers for hw events. Both can be extended 
gradually, without arbitrarily limits introduced.

	Ingo

------------------------->
>From 447557ac7ce120306b4a31d6003faef39cb1bf14 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 11 Dec 2008 20:40:18 +0100
Subject: [PATCH] perf counters: update docs

Impact: update docs

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/perf-counters.txt |  107 +++++++++++++++++++++++++++------------
 1 files changed, 75 insertions(+), 32 deletions(-)

diff --git a/Documentation/perf-counters.txt b/Documentation/perf-counters.txt
index 19033a0..fddd321 100644
--- a/Documentation/perf-counters.txt
+++ b/Documentation/perf-counters.txt
@@ -10,8 +10,8 @@ trigger interrupts when a threshold number of events have passed - and can
 thus be used to profile the code that runs on that CPU.
 
 The Linux Performance Counter subsystem provides an abstraction of these
-hardware capabilities. It provides per task and per CPU counters, and
-it provides event capabilities on top of those.
+hardware capabilities. It provides per task and per CPU counters, counter
+groups, and it provides event capabilities on top of those.
 
 Performance counters are accessed via special file descriptors.
 There's one file descriptor per virtual counter used.
@@ -19,12 +19,8 @@ There's one file descriptor per virtual counter used.
 The special file descriptor is opened via the perf_counter_open()
 system call:
 
- int
- perf_counter_open(u32 hw_event_type,
-                   u32 hw_event_period,
-                   u32 record_type,
-                   pid_t pid,
-                   int cpu);
+   int sys_perf_counter_open(struct perf_counter_hw_event *hw_event_uptr,
+			     pid_t pid, int cpu, int group_fd);
 
 The syscall returns the new fd. The fd can be used via the normal
 VFS system calls: read() can be used to read the counter, fcntl()
@@ -33,39 +29,78 @@ can be used to set the blocking mode, etc.
 Multiple counters can be kept open at a time, and the counters
 can be poll()ed.
 
-When creating a new counter fd, 'hw_event_type' is one of:
-
- enum hw_event_types {
-	PERF_COUNT_CYCLES,
-	PERF_COUNT_INSTRUCTIONS,
-	PERF_COUNT_CACHE_REFERENCES,
-	PERF_COUNT_CACHE_MISSES,
-	PERF_COUNT_BRANCH_INSTRUCTIONS,
-	PERF_COUNT_BRANCH_MISSES,
- };
+When creating a new counter fd, 'perf_counter_hw_event' is:
+
+/*
+ * Hardware event to monitor via a performance monitoring counter:
+ */
+struct perf_counter_hw_event {
+	s64			type;
+
+	u64			irq_period;
+	u32			record_type;
+
+	u32			disabled     :  1, /* off by default */
+				nmi	     :  1, /* NMI sampling   */
+				raw	     :  1, /* raw event type */
+				__reserved_1 : 29;
+
+	u64			__reserved_2;
+};
+
+/*
+ * Generalized performance counter event types, used by the hw_event.type
+ * parameter of the sys_perf_counter_open() syscall:
+ */
+enum hw_event_types {
+	/*
+	 * Common hardware events, generalized by the kernel:
+	 */
+	PERF_COUNT_CYCLES		=  0,
+	PERF_COUNT_INSTRUCTIONS		=  1,
+	PERF_COUNT_CACHE_REFERENCES	=  2,
+	PERF_COUNT_CACHE_MISSES		=  3,
+	PERF_COUNT_BRANCH_INSTRUCTIONS	=  4,
+	PERF_COUNT_BRANCH_MISSES	=  5,
+
+	/*
+	 * Special "software" counters provided by the kernel, even if
+	 * the hardware does not support performance counters. These
+	 * counters measure various physical and sw events of the
+	 * kernel (and allow the profiling of them as well):
+	 */
+	PERF_COUNT_CPU_CLOCK		= -1,
+	PERF_COUNT_TASK_CLOCK		= -2,
+	/*
+	 * Future software events:
+	 */
+	/* PERF_COUNT_PAGE_FAULTS	= -3,
+	   PERF_COUNT_CONTEXT_SWITCHES	= -4, */
+};
 
 These are standardized types of events that work uniformly on all CPUs
 that implements Performance Counters support under Linux. If a CPU is
 not able to count branch-misses, then the system call will return
 -EINVAL.
 
-[ Note: more hw_event_types are supported as well, but they are CPU
-  specific and are enumerated via /sys on a per CPU basis. Raw hw event
-  types can be passed in as negative numbers. For example, to count
-  "External bus cycles while bus lock signal asserted" events on Intel
-  Core CPUs, pass in a -0x4064 event type value. ]
-
-The parameter 'hw_event_period' is the number of events before waking up
-a read() that is blocked on a counter fd. Zero value means a non-blocking
-counter.
+More hw_event_types are supported as well, but they are CPU
+specific and are enumerated via /sys on a per CPU basis. Raw hw event
+types can be passed in under hw_event.type if hw_event.raw is 1.
+For example, to count "External bus cycles while bus lock signal asserted"
+events on Intel Core CPUs, pass in a 0x4064 event type value and set
+hw_event.raw to 1.
 
 'record_type' is the type of data that a read() will provide for the
 counter, and it can be one of:
 
-  enum perf_record_type {
-	PERF_RECORD_SIMPLE,
-	PERF_RECORD_IRQ,
-  };
+/*
+ * IRQ-notification data record type:
+ */
+enum perf_counter_record_type {
+	PERF_RECORD_SIMPLE		=  0,
+	PERF_RECORD_IRQ			=  1,
+	PERF_RECORD_GROUP		=  2,
+};
 
 a "simple" counter is one that counts hardware events and allows
 them to be read out into a u64 count value. (read() returns 8 on
@@ -76,6 +111,10 @@ the IP of the interrupted context. In this case read() will return
 the 8-byte counter value, plus the Instruction Pointer address of the
 interrupted context.
 
+The parameter 'hw_event_period' is the number of events before waking up
+a read() that is blocked on a counter fd. Zero value means a non-blocking
+counter.
+
 The 'pid' parameter allows the counter to be specific to a task:
 
  pid == 0: if the pid parameter is zero, the counter is attached to the
@@ -92,7 +131,7 @@ CPU:
  cpu >= 0: the counter is restricted to a specific CPU
  cpu == -1: the counter counts on all CPUs
 
-Note: the combination of 'pid == -1' and 'cpu == -1' is not valid.
+(Note: the combination of 'pid == -1' and 'cpu == -1' is not valid.)
 
 A 'pid > 0' and 'cpu == -1' counter is a per task counter that counts
 events of that task and 'follows' that task to whatever CPU the task
@@ -102,3 +141,7 @@ their own tasks.
 A 'pid == -1' and 'cpu == x' counter is a per CPU counter that counts
 all events on CPU-x. Per CPU counters need CAP_SYS_ADMIN privilege.
 
+Group counters are created by passing in a group_fd of another counter.
+Groups are scheduled at once and can be used with PERF_RECORD_GROUP
+to record multi-dimensional timestamps.
+

  reply	other threads:[~2008-12-11 19:50 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11 15:52 Ingo Molnar
2008-12-11 18:02 ` Vince Weaver
2008-12-12  8:25   ` Peter Zijlstra
2008-12-12  8:35     ` stephane eranian
2008-12-12  8:51       ` Peter Zijlstra
2008-12-12  9:00         ` Peter Zijlstra
2008-12-12  9:07           ` Ingo Molnar
2008-12-12  8:59     ` stephane eranian
2008-12-12  9:23       ` Peter Zijlstra
2008-12-12 10:21         ` Robert Richter
2008-12-12 10:59           ` Christoph Hellwig
2008-12-12 11:35             ` Robert Richter
2008-12-12 16:45         ` Chris Friesen
2008-12-12 17:42         ` stephane eranian
2008-12-12 18:01           ` stephane eranian
2008-12-12 19:45             ` Chris Friesen
2008-12-15 14:50               ` stephane eranian
2008-12-15 22:32                 ` Chris Friesen
2008-12-17  7:45                   ` stephane eranian
2008-12-14 23:13             ` Ingo Molnar
2008-12-15  0:37               ` Paul Mackerras
2008-12-15 12:58                 ` stephane eranian
2008-12-15 14:42                 ` stephane eranian
2008-12-15 20:58               ` stephane eranian
2008-12-15 22:53               ` Paul Mackerras
2008-12-13 11:17           ` Peter Zijlstra
2008-12-13 13:48             ` Henrique de Moraes Holschuh
2008-12-13 17:44             ` stephane eranian
2008-12-14  1:02             ` Paul Mackerras
2008-12-14 22:37               ` Ingo Molnar
2008-12-15  0:50                 ` Paul Mackerras
2008-12-15 13:02                   ` stephane eranian
2008-12-12 17:03     ` Samuel Thibault
2008-12-12 17:11       ` Peter Zijlstra
2008-12-12 18:18     ` Vince Weaver
2008-12-11 18:35 ` Andrew Morton
2008-12-12  6:22   ` Ingo Molnar
2008-12-11 19:11 ` Tony Luck
2008-12-11 19:34   ` Ingo Molnar [this message]
2008-12-12  8:29     ` Peter Zijlstra
2008-12-12  8:54       ` Ingo Molnar
2008-12-12 13:42       ` Andi Kleen
2008-12-14 14:51 ` Performance counter API review was " Andi Kleen
2009-02-02 20:03   ` Corey Ashford
2009-02-02 20:33     ` Peter Zijlstra
2009-02-03 16:53       ` Maynard Johnson
2009-02-04  2:18       ` Paul Mackerras
2009-02-04  2:32         ` Nathan Lynch
2009-02-04  8:45         ` Peter Zijlstra
2009-02-04 10:47           ` Paul Mackerras
2009-02-04 10:51             ` Peter Zijlstra
2008-12-11 22:05 William Cohen

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=20081211193439.GA25986@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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®