Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1289573 > unrolled thread

[PATCH v0 0/5] perf: Introduce instruction trace filtering

Back to article view | Back to linux.kernel

Contents

  [PATCH v0 0/5] perf: Introduce instruction trace filtering Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-11 14:40 +0100
    [PATCH v0 1/5] perf: Move set_filter() from behind EVENT_TRACING Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-11 14:40 +0100
    [PATCH v0 2/5] perf: Extend perf_event_aux() to optionally iterate through more events Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-11 14:40 +0100
    [PATCH v0 4/5] perf/x86/intel/pt: IP filtering register/cpuid bits Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-11 14:40 +0100
    Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering Mathieu Poirier <mathieu.poirier@linaro.org> - 2015-12-11 22:40 +0100
      Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-14 10:00 +0100
        Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering Mathieu Poirier <mathieu.poirier@linaro.org> - 2015-12-15 01:30 +0100

#1289573 — [PATCH v0 0/5] perf: Introduce instruction trace filtering

Hi Peter,

Newer version of Intel PT supports address-based filtering, and this
patchset adds support for it to perf core and the PT pmu driver. It
works by configuring a number of address ranges in hardware and
telling it to use these ranges to filter its traces. Similar feature
also exists in ARM Coresight ETM/PTM and it is also taken into account
in this patchset.

Firstly, userspace configures filters via an ioctl(), filters are
formatted as an ascii string. Filters may refer to addresses in object
files for userspace code or kernel addresses. The latter might be
extended in the future to support kernel modules.

For userspace filters, we scan the task's vmas to see if any of them
match the defined filters (inode+offset) and if they do, calculate
memory offsets and program them into hardware. Note that since
different tasks will have different mappings for the same object
files, supporting cpu-wide events would require special tricks to
context-switch filters for userspace code.

Also, we monitor new mmap and exec events to update (or clear) filter
configuration.

This is based on my perf_mmap_close() patchset from yesterday [1], which
in turn is based on your perf/core queue.

[1] http://marc.info/?l=linux-kernel&m=144976438631073

Alexander Shishkin (5):
  perf: Move set_filter() from behind EVENT_TRACING
  perf: Extend perf_event_aux() to optionally iterate through more
    events
  perf: Introduce instruction trace filtering
  perf/x86/intel/pt: IP filtering register/cpuid bits
  perf/x86/intel/pt: Add support for instruction trace filtering in PT

 arch/x86/include/asm/msr-index.h          |  18 +
 arch/x86/kernel/cpu/intel_pt.h            |  32 +-
 arch/x86/kernel/cpu/perf_event_intel_pt.c | 134 +++++-
 include/linux/perf_event.h                |  40 ++
 kernel/events/core.c                      | 655 ++++++++++++++++++++++++++++--
 5 files changed, 835 insertions(+), 44 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1289574 — [PATCH v0 1/5] perf: Move set_filter() from behind EVENT_TRACING

For instruction trace filtering, namely, for communicating filter
definitions from userspace, I'd like to re-use the SET_FILTER code
that the tracepoints are using currently.

To that end, this patch moves the relevant code from behind EVENT_TRACING
macro.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 kernel/events/core.c | 45 ++++++++++++++++++++++-----------------------
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 05a50b4fb9..0b28116dd7 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7078,24 +7078,6 @@ static inline void perf_tp_register(void)
 	perf_pmu_register(&perf_tracepoint, "tracepoint", PERF_TYPE_TRACEPOINT);
 }
 
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-	char *filter_str;
-	int ret;
-
-	if (event->attr.type != PERF_TYPE_TRACEPOINT)
-		return -EINVAL;
-
-	filter_str = strndup_user(arg, PAGE_SIZE);
-	if (IS_ERR(filter_str))
-		return PTR_ERR(filter_str);
-
-	ret = ftrace_profile_set_filter(event, event->attr.config, filter_str);
-
-	kfree(filter_str);
-	return ret;
-}
-
 static void perf_event_free_filter(struct perf_event *event)
 {
 	ftrace_profile_free_filter(event);
@@ -7150,11 +7132,6 @@ static inline void perf_tp_register(void)
 {
 }
 
-static int perf_event_set_filter(struct perf_event *event, void __user *arg)
-{
-	return -ENOENT;
-}
-
 static void perf_event_free_filter(struct perf_event *event)
 {
 }
@@ -7182,6 +7159,28 @@ void perf_bp_event(struct perf_event *bp, void *data)
 }
 #endif
 
+static int perf_event_set_filter(struct perf_event *event, void __user *arg)
+{
+	char *filter_str;
+	int ret = -EINVAL;
+
+	if (event->attr.type != PERF_TYPE_TRACEPOINT ||
+	    !IS_ENABLED(CONFIG_EVENT_TRACING))
+		return -EINVAL;
+
+	filter_str = strndup_user(arg, PAGE_SIZE);
+	if (IS_ERR(filter_str))
+		return PTR_ERR(filter_str);
+
+	if (IS_ENABLED(CONFIG_EVENT_TRACING) &&
+	    event->attr.type == PERF_TYPE_TRACEPOINT)
+		ret = ftrace_profile_set_filter(event, event->attr.config,
+						filter_str);
+
+	kfree(filter_str);
+	return ret;
+}
+
 /*
  * hrtimer based swevent callback
  */
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289578 — [PATCH v0 2/5] perf: Extend perf_event_aux() to optionally iterate through more events

Trace filtering code needs an iterator that can go through all events,
including inactive and filtered, to be able to update their filters'
ranges based on mmap or exec events.

This patch changes perf_event_aux() to optionally do this.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 kernel/events/core.c | 38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0b28116dd7..2bab4af901 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5642,33 +5642,36 @@ typedef void (perf_event_aux_output_cb)(struct perf_event *event, void *data);
 static void
 perf_event_aux_ctx(struct perf_event_context *ctx,
 		   perf_event_aux_output_cb output,
-		   void *data)
+		   void *data, bool all)
 {
 	struct perf_event *event;
 
 	list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
-		if (event->state < PERF_EVENT_STATE_INACTIVE)
-			continue;
-		if (!event_filter_match(event))
-			continue;
+		if (!all) {
+			if (event->state < PERF_EVENT_STATE_INACTIVE)
+				continue;
+			if (!event_filter_match(event))
+				continue;
+		}
+
 		output(event, data);
 	}
 }
 
 static void
 perf_event_aux_task_ctx(perf_event_aux_output_cb output, void *data,
-			struct perf_event_context *task_ctx)
+			struct perf_event_context *task_ctx, bool all)
 {
 	rcu_read_lock();
 	preempt_disable();
-	perf_event_aux_ctx(task_ctx, output, data);
+	perf_event_aux_ctx(task_ctx, output, data, all);
 	preempt_enable();
 	rcu_read_unlock();
 }
 
 static void
 perf_event_aux(perf_event_aux_output_cb output, void *data,
-	       struct perf_event_context *task_ctx)
+	       struct perf_event_context *task_ctx, bool all)
 {
 	struct perf_cpu_context *cpuctx;
 	struct perf_event_context *ctx;
@@ -5682,7 +5685,7 @@ perf_event_aux(perf_event_aux_output_cb output, void *data,
 	 * context.
 	 */
 	if (task_ctx) {
-		perf_event_aux_task_ctx(output, data, task_ctx);
+		perf_event_aux_task_ctx(output, data, task_ctx, all);
 		return;
 	}
 
@@ -5691,13 +5694,13 @@ perf_event_aux(perf_event_aux_output_cb output, void *data,
 		cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
 		if (cpuctx->unique_pmu != pmu)
 			goto next;
-		perf_event_aux_ctx(&cpuctx->ctx, output, data);
+		perf_event_aux_ctx(&cpuctx->ctx, output, data, all);
 		ctxn = pmu->task_ctx_nr;
 		if (ctxn < 0)
 			goto next;
 		ctx = rcu_dereference(current->perf_event_ctxp[ctxn]);
 		if (ctx)
-			perf_event_aux_ctx(ctx, output, data);
+			perf_event_aux_ctx(ctx, output, data, all);
 next:
 		put_cpu_ptr(pmu->pmu_cpu_context);
 	}
@@ -5725,10 +5728,11 @@ static int __perf_pmu_output_stop(void *info)
 	struct perf_cpu_context *cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
 
 	rcu_read_lock();
-	perf_event_aux_ctx(&cpuctx->ctx, __perf_event_output_stop, event->rb);
+	perf_event_aux_ctx(&cpuctx->ctx, __perf_event_output_stop, event->rb,
+			   false);
 	if (cpuctx->task_ctx)
 		perf_event_aux_ctx(cpuctx->task_ctx, __perf_event_output_stop,
-				   event->rb);
+				   event->rb, false);
 	rcu_read_unlock();
 
 	return 0;
@@ -5840,7 +5844,7 @@ static void perf_event_task(struct task_struct *task,
 
 	perf_event_aux(perf_event_task_output,
 		       &task_event,
-		       task_ctx);
+		       task_ctx, false);
 }
 
 void perf_event_fork(struct task_struct *task)
@@ -5919,7 +5923,7 @@ static void perf_event_comm_event(struct perf_comm_event *comm_event)
 
 	perf_event_aux(perf_event_comm_output,
 		       comm_event,
-		       NULL);
+		       NULL, false);
 }
 
 void perf_event_comm(struct task_struct *task, bool exec)
@@ -6150,7 +6154,7 @@ got_name:
 
 	perf_event_aux(perf_event_mmap_output,
 		       mmap_event,
-		       NULL);
+		       NULL, false);
 
 	kfree(buf);
 }
@@ -6338,7 +6342,7 @@ static void perf_event_switch(struct task_struct *task,
 
 	perf_event_aux(perf_event_switch_output,
 		       &switch_event,
-		       NULL);
+		       NULL, false);
 }
 
 /*
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289581 — [PATCH v0 4/5] perf/x86/intel/pt: IP filtering register/cpuid bits

New versions of Intel PT support address range-based filtering. These
are the registers, bit definitions and relevant CPUID bits.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 arch/x86/include/asm/msr-index.h          | 18 ++++++++++++++++++
 arch/x86/kernel/cpu/intel_pt.h            |  2 ++
 arch/x86/kernel/cpu/perf_event_intel_pt.c |  2 ++
 3 files changed, 22 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 690b4027e1..fbbe21bcca 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -100,11 +100,29 @@
 #define RTIT_CTL_CYC_THRESH		(0x0full << RTIT_CTL_CYC_THRESH_OFFSET)
 #define RTIT_CTL_PSB_FREQ_OFFSET	24
 #define RTIT_CTL_PSB_FREQ      		(0x0full << RTIT_CTL_PSB_FREQ_OFFSET)
+#define RTIT_CTL_ADDR0_OFFSET		32
+#define RTIT_CTL_ADDR0      		(0x0full << RTIT_CTL_ADDR0_OFFSET)
+#define RTIT_CTL_ADDR1_OFFSET		36
+#define RTIT_CTL_ADDR1      		(0x0full << RTIT_CTL_ADDR1_OFFSET)
+#define RTIT_CTL_ADDR2_OFFSET		40
+#define RTIT_CTL_ADDR2      		(0x0full << RTIT_CTL_ADDR2_OFFSET)
+#define RTIT_CTL_ADDR3_OFFSET		44
+#define RTIT_CTL_ADDR3      		(0x0full << RTIT_CTL_ADDR3_OFFSET)
 #define MSR_IA32_RTIT_STATUS		0x00000571
+#define RTIT_STATUS_FILTEREN		BIT(0)
 #define RTIT_STATUS_CONTEXTEN		BIT(1)
 #define RTIT_STATUS_TRIGGEREN		BIT(2)
+#define RTIT_STATUS_BUFFOVF		BIT(3)
 #define RTIT_STATUS_ERROR		BIT(4)
 #define RTIT_STATUS_STOPPED		BIT(5)
+#define MSR_IA32_RTIT_ADDR0_A		0x00000580
+#define MSR_IA32_RTIT_ADDR0_B		0x00000581
+#define MSR_IA32_RTIT_ADDR1_A		0x00000582
+#define MSR_IA32_RTIT_ADDR1_B		0x00000583
+#define MSR_IA32_RTIT_ADDR2_A		0x00000584
+#define MSR_IA32_RTIT_ADDR2_B		0x00000585
+#define MSR_IA32_RTIT_ADDR3_A		0x00000586
+#define MSR_IA32_RTIT_ADDR3_B		0x00000587
 #define MSR_IA32_RTIT_CR3_MATCH		0x00000572
 #define MSR_IA32_RTIT_OUTPUT_BASE	0x00000560
 #define MSR_IA32_RTIT_OUTPUT_MASK	0x00000561
diff --git a/arch/x86/kernel/cpu/intel_pt.h b/arch/x86/kernel/cpu/intel_pt.h
index 336878a5d2..6ce8cd20b9 100644
--- a/arch/x86/kernel/cpu/intel_pt.h
+++ b/arch/x86/kernel/cpu/intel_pt.h
@@ -52,11 +52,13 @@ enum pt_capabilities {
 	PT_CAP_max_subleaf = 0,
 	PT_CAP_cr3_filtering,
 	PT_CAP_psb_cyc,
+	PT_CAP_ip_filtering,
 	PT_CAP_mtc,
 	PT_CAP_topa_output,
 	PT_CAP_topa_multiple_entries,
 	PT_CAP_single_range_output,
 	PT_CAP_payloads_lip,
+	PT_CAP_num_address_ranges,
 	PT_CAP_mtc_periods,
 	PT_CAP_cycle_thresholds,
 	PT_CAP_psb_periods,
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index daf5f6caf8..2ec25581de 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -67,11 +67,13 @@ static struct pt_cap_desc {
 	PT_CAP(max_subleaf,		0, CR_EAX, 0xffffffff),
 	PT_CAP(cr3_filtering,		0, CR_EBX, BIT(0)),
 	PT_CAP(psb_cyc,			0, CR_EBX, BIT(1)),
+	PT_CAP(ip_filtering,		0, CR_EBX, BIT(2)),
 	PT_CAP(mtc,			0, CR_EBX, BIT(3)),
 	PT_CAP(topa_output,		0, CR_ECX, BIT(0)),
 	PT_CAP(topa_multiple_entries,	0, CR_ECX, BIT(1)),
 	PT_CAP(single_range_output,	0, CR_ECX, BIT(2)),
 	PT_CAP(payloads_lip,		0, CR_ECX, BIT(31)),
+	PT_CAP(num_address_ranges,	1, CR_EAX, 0x3),
 	PT_CAP(mtc_periods,		1, CR_EAX, 0xffff0000),
 	PT_CAP(cycle_thresholds,	1, CR_EBX, 0xffff),
 	PT_CAP(psb_periods,		1, CR_EBX, 0xffff0000),
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289929

On 11 December 2015 at 06:36, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Hi Peter,
>
> Newer version of Intel PT supports address-based filtering, and this
> patchset adds support for it to perf core and the PT pmu driver. It
> works by configuring a number of address ranges in hardware and
> telling it to use these ranges to filter its traces. Similar feature
> also exists in ARM Coresight ETM/PTM and it is also taken into account
> in this patchset.
>
> Firstly, userspace configures filters via an ioctl(), filters are
> formatted as an ascii string. Filters may refer to addresses in object
> files for userspace code or kernel addresses. The latter might be
> extended in the future to support kernel modules.
>
> For userspace filters, we scan the task's vmas to see if any of them
> match the defined filters (inode+offset) and if they do, calculate
> memory offsets and program them into hardware. Note that since
> different tasks will have different mappings for the same object
> files, supporting cpu-wide events would require special tricks to
> context-switch filters for userspace code.
>
> Also, we monitor new mmap and exec events to update (or clear) filter
> configuration.
>
> This is based on my perf_mmap_close() patchset from yesterday [1], which
> in turn is based on your perf/core queue.
>
> [1] http://marc.info/?l=linux-kernel&m=144976438631073
>
> Alexander Shishkin (5):
>   perf: Move set_filter() from behind EVENT_TRACING
>   perf: Extend perf_event_aux() to optionally iterate through more
>     events
>   perf: Introduce instruction trace filtering
>   perf/x86/intel/pt: IP filtering register/cpuid bits
>   perf/x86/intel/pt: Add support for instruction trace filtering in PT
>
>  arch/x86/include/asm/msr-index.h          |  18 +
>  arch/x86/kernel/cpu/intel_pt.h            |  32 +-
>  arch/x86/kernel/cpu/perf_event_intel_pt.c | 134 +++++-
>  include/linux/perf_event.h                |  40 ++
>  kernel/events/core.c                      | 655 ++++++++++++++++++++++++++++--
>  5 files changed, 835 insertions(+), 44 deletions(-)
>
> --
> 2.6.2
>

Alex, Peter and al,

As I mentioned in a previous reply I think this patchset is aiming in
the right direction.  Here we are dealing with address range
filtering, something that is common to both IntelPT and CS, but what
happens when we want introduce options that aren't generic to all
tracers and still want to us the ioctl method?

Can we make the current scheme more extensible or generic so that
adding more architecture specific option is easily feasible?

Thanks for the consideration,
Mathieu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1290985

Mathieu Poirier <mathieu.poirier@linaro.org> writes:

> On 11 December 2015 at 06:36, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
> Alex, Peter and al,
>
> As I mentioned in a previous reply I think this patchset is aiming in
> the right direction.  Here we are dealing with address range
> filtering, something that is common to both IntelPT and CS, but what
> happens when we want introduce options that aren't generic to all
> tracers and still want to us the ioctl method?

Are we still talking about filtering options or more like event
configuration? First, we need to understand if one particular feature or
an option should be enabled for the entire lifetime of an event or if it
should be configurable on the fly. For the former, you can use
attr.config and friends, for the latter it makes sense to use an ioctl.

If we're still talking about address range filtering, there is one
difference in coresight that I'm aware of, which is specifying
individual addresses as start/stop triggers (as opposed to enable
ranges) and that is already taken care of in the current parser, I
should probably write a comment to make it more apparent.

So my approach was to not consider them to be architecture specific
features, but simply features that either are or aren't supported by a
particular pmu.

> Can we make the current scheme more extensible or generic so that
> adding more architecture specific option is easily feasible?

Well, the bigger question is, how do you represent a very architecture
specific option in the core structures. I have one solution to that that
is described above. It shouldn't take much architecture-specific code to
handle each new option, unless it something that really only makes sense
for one architecture/pmu.

All that said, one could still extend the current code quite easily to
fit completely non-generic things. In the default clause, in the parser
function, one could add:

  if (state == IF_STATE_ACTION)
      if (event->pmu->itrace_filter_parse(event, &filter))
          goto fail;

if one really had to.

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291724

On 14 December 2015 at 01:50, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>
>> On 11 December 2015 at 06:36, Alexander Shishkin
>> <alexander.shishkin@linux.intel.com> wrote:
>> Alex, Peter and al,
>>
>> As I mentioned in a previous reply I think this patchset is aiming in
>> the right direction.  Here we are dealing with address range
>> filtering, something that is common to both IntelPT and CS, but what
>> happens when we want introduce options that aren't generic to all
>> tracers and still want to us the ioctl method?
>
> Are we still talking about filtering options or more like event
> configuration? First, we need to understand if one particular feature or
> an option should be enabled for the entire lifetime of an event or if it
> should be configurable on the fly. For the former, you can use
> attr.config and friends, for the latter it makes sense to use an ioctl.
> If we're still talking about address range filtering, there is one
> difference in coresight that I'm aware of, which is specifying
> individual addresses as start/stop triggers (as opposed to enable
> ranges) and that is already taken care of in the current parser, I
> should probably write a comment to make it more apparent.

Yes, I saw that option.

>
> So my approach was to not consider them to be architecture specific
> features, but simply features that either are or aren't supported by a
> particular pmu.
>
>> Can we make the current scheme more extensible or generic so that
>> adding more architecture specific option is easily feasible?
>
> Well, the bigger question is, how do you represent a very architecture
> specific option in the core structures. I have one solution to that that
> is described above. It shouldn't take much architecture-specific code to
> handle each new option, unless it something that really only makes sense
> for one architecture/pmu.
>
> All that said, one could still extend the current code quite easily to
> fit completely non-generic things. In the default clause, in the parser
> function, one could add:
>
>   if (state == IF_STATE_ACTION)
>       if (event->pmu->itrace_filter_parse(event, &filter))
>           goto fail;
>
> if one really had to.

What I had in mind is more advanced tracing features like state
machines and counters but in hindsight I have no plans to play with
those any time soon.

What's more pressing is the need to be able to select the sink that
will gather the trace data from the perf cmd line tool.  At this time
it is a two step process that needs to be fixed.  At first I was
thinking about something like:

perf record -e cs_etm/sink:XYZ.tmc/

But from what I gathered it won't be easily feasible without changing
a lot of things - I think your ioctl() mechanism is much better for
something like that.  And sink selection a one time thing that doesn't
change throughout the trace session.

Based on what I found on the internet one would use ioctl() like this:

perf record -e intel_pt// --filter kernel:0x80000/0x1000

As such and thinking along the same lines I could fix my sink
enablement problem like this:

perf record -e intel_pt// --filter sink:XYZ.tmc

But a sink isn't a filter.  Maybe using the PERF_EVENT_IOC_SET_OUTPUT
would be a better choice but then again, a sink isn't a file.  So I'm
a little puzzled here.  Maybe Peter or Arnaldo would be able to advise
here...

Long story short my request to make things more generic can be put to rest.

Thanks,
Mathieu

>
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web