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


Groups > linux.kernel > #1283359 > unrolled thread

[PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event

Started byMathieu Poirier <mathieu.poirier@linaro.org>
First post2015-12-03 22:10 +0100
Last post2015-12-11 23:00 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event Mathieu Poirier <mathieu.poirier@linaro.org> - 2015-12-03 22:10 +0100
    Re: [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-11 15:20 +0100
      Re: [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to  include event Mathieu Poirier <mathieu.poirier@linaro.org> - 2015-12-11 23:00 +0100

#1283359 — [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event

FromMathieu Poirier <mathieu.poirier@linaro.org>
Date2015-12-03 22:10 +0100
Subject[PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event
Message-ID<qBJiy-1Vy-5@gated-at.bofh.it>
For Coresight ETMv3/4 tracers the event carries information
about trace modes such as user or kernel space tracing and
whether tracing is allowed when operating in secure mode.

Since this information is to be embedded in the private
structure returned by setup_aux(),  changing the first
parameter to be of type struct perf_event * so that all
the necessary information can be conveyed.  Also changing
current customer of the API to reflect the modification.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/x86/kernel/cpu/perf_event_intel_bts.c | 4 +++-
 arch/x86/kernel/cpu/perf_event_intel_pt.c  | 5 +++--
 include/linux/perf_event.h                 | 2 +-
 kernel/events/ring_buffer.c                | 2 +-
 4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_bts.c b/arch/x86/kernel/cpu/perf_event_intel_bts.c
index 2cad71d1b14c..4bb5bdc092f5 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_bts.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_bts.c
@@ -68,10 +68,12 @@ static size_t buf_size(struct page *page)
 }
 
 static void *
-bts_buffer_setup_aux(int cpu, void **pages, int nr_pages, bool overwrite)
+bts_buffer_setup_aux(struct perf_event *event, void **pages,
+		     int nr_pages, bool overwrite)
 {
 	struct bts_buffer *buf;
 	struct page *page;
+	int cpu = event->cpu;
 	int node = (cpu == -1) ? cpu : cpu_to_node(cpu);
 	unsigned long offset;
 	size_t size = nr_pages << PAGE_SHIFT;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index 868e1194337f..ba8077cbc755 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -860,10 +860,11 @@ static int pt_buffer_init_topa(struct pt_buffer *buf, unsigned long nr_pages,
  * Return:	Our private PT buffer structure.
  */
 static void *
-pt_buffer_setup_aux(int cpu, void **pages, int nr_pages, bool snapshot)
+pt_buffer_setup_aux(struct perf_event *event, void **pages,
+		    int nr_pages, bool snapshot)
 {
 	struct pt_buffer *buf;
-	int node, ret;
+	int node, ret, cpu = event->cpu;
 
 	if (!nr_pages)
 		return NULL;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index d841d33bcdc9..da02d4a0baa2 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -378,7 +378,7 @@ struct pmu {
 	/*
 	 * Set up pmu-private data structures for an AUX area
 	 */
-	void *(*setup_aux)		(int cpu, void **pages,
+	void *(*setup_aux)		(struct perf_event *event, void **pages,
 					 int nr_pages, bool overwrite);
 					/* optional */
 
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index b5d1ea79c595..b1316d12bb40 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -522,7 +522,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event *event,
 			goto out;
 	}
 
-	rb->aux_priv = event->pmu->setup_aux(event->cpu, rb->aux_pages, nr_pages,
+	rb->aux_priv = event->pmu->setup_aux(event, rb->aux_pages, nr_pages,
 					     overwrite);
 	if (!rb->aux_priv)
 		goto out;
-- 
2.1.4

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


#1289615

FromAlexander Shishkin <alexander.shishkin@linux.intel.com>
Date2015-12-11 15:20 +0100
Message-ID<qEwIa-5Bq-23@gated-at.bofh.it>
In reply to#1283359
Mathieu Poirier <mathieu.poirier@linaro.org> writes:

> For Coresight ETMv3/4 tracers the event carries information
> about trace modes such as user or kernel space tracing and
> whether tracing is allowed when operating in secure mode.

Ok, so it looks to me that what you're doing in your setup_aux with the
event, you should rather be doing in pmu::event_init(), which takes
event as a parameter and it even makes more sense semantically, because
that bit is really configuring the parameters of tracing and not
capturing, which setup_aux() is more about. And the above paragraph also
sounds very much like it. Since in Coresight there is a very clear
distinction between trace generation (sources) and capturing (sinks) it
should also be possible to structure the code in such a way that the
former are not as closely tied to the latter. Please correct me if I'm
missing something.

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]


#1289938 — Re: [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event

FromMathieu Poirier <mathieu.poirier@linaro.org>
Date2015-12-11 23:00 +0100
SubjectRe: [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event
Message-ID<qEDTk-1BH-9@gated-at.bofh.it>
In reply to#1289615
On 11 December 2015 at 07:12, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>
>> For Coresight ETMv3/4 tracers the event carries information
>> about trace modes such as user or kernel space tracing and
>> whether tracing is allowed when operating in secure mode.
>
> Ok, so it looks to me that what you're doing in your setup_aux with the
> event, you should rather be doing in pmu::event_init(), which takes
> event as a parameter and it even makes more sense semantically, because
> that bit is really configuring the parameters of tracing and not
> capturing, which setup_aux() is more about. And the above paragraph also
> sounds very much like it. Since in Coresight there is a very clear
> distinction between trace generation (sources) and capturing (sinks) it
> should also be possible to structure the code in such a way that the
> former are not as closely tied to the latter. Please correct me if I'm
> missing something.

Conceptually there is no need to do the configuration for source, path
and sink in setup_aux() but all this information has to be kept
somewhere...  Since setup_aux() is where the private data structure
that will be used for the rest of the trace session gets created I
didn't see another way.

But with your patchset on trace filtering [1] I'm pretty sure we don't
need to do tracer configuration for all the tracers at the beginning.
I have to double check a few things but it is very likely that CS
tracer configuration can be made the same way PT is done, something
that will seriously simplify the setup process.

That leaves us with the path from source to sink - it is event
specific and as such needs to be part of the private data structure.
Unless you see a better way to proceed it will stay in setup_aux...

Thanks for the review,
Mathieu

[1]. https://lkml.org/lkml/2015/12/11/449

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