LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Vince Weaver <vince@deater.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@kernel.org>
Subject: Re: perf group read for inherited events
Date: Tue, 30 May 2017 11:45:12 +0200
Message-ID: <20170530094512.dy2nljns2uq7qa3j@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20170526205601.GA5271@tassilo.jf.intel.com>



On Fri, May 26, 2017 at 01:56:01PM -0700, Andi Kleen wrote:

> I have a need for read group reads for inherited events.
> 
> It looks like the perf group read code already has all the code
> to handle inheritance, __perf_read_group_add walks
> the children list and adds them all up.
> 
>    4409 
>    4410         list_for_each_entry(sub, &leader->sibling_list, group_entry) {
>    4411                 values[n++] += perf_event_count(sub);
>    4412                 if (read_format & PERF_FORMAT_ID)
>    4413                         values[n++] = primary_event_id(sub);
>    4414         }
> 
> 
> I disabled the check that forbids this and it seems to work
> from some simple testing.
> 
> Again do I miss something why this was disabled?

The thing that seems difficult is PERF_SAMPLE_READ vs inherited,
irrespective of PERF_FORMAT_GROUP.

The error seems to be in that patch you fingered:

  3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")


-       PERF_SAMPLE_GROUP                       = 1U << 4,
+       PERF_SAMPLE_READ                        = 1U << 4,

-       if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP))
+       if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))

is a clear fail :/

> Perhaps some locking issue? There are some comments on it,
> but I'm not sure I understand all the subtleties:
> 
>         /*
>          * By locking the child_mutex of the leader we effectively
>          * lock the child list of all siblings.. XXX explain how.
>          */
>         mutex_lock(&leader->child_mutex);

This is more recent. Here I failed to find a coherent text to explain
the locking. It is correct through. I think its something like:

@@ -4426,8 +4426,9 @@ static int perf_read_group(struct perf_event *event,
 	values[0] = 1 + leader->nr_siblings;
 
 	/*
-	 * By locking the child_mutex of the leader we effectively
-	 * lock the child list of all siblings.. XXX explain how.
+	 * By locking the child_mutex of the leader we effectively lock the
+	 * child list of all siblings. Since inherit_group() will first clone
+	 * the leader and will this be blocked on us holding its child_mutex.
 	 */
 	mutex_lock(&leader->child_mutex);
 

> Or is the simple patch below good enough?

The below seems to be the correct thing. It is rather unfortunate that
this would break/significantly change existing semantics :/

---
 kernel/events/core.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8d6acaeeea17..2d9de6fb9a5a 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5722,9 +5722,6 @@ static void perf_output_read_one(struct perf_output_handle *handle,
 	__output_copy(handle, values, n * sizeof(u64));
 }
 
-/*
- * XXX PERF_FORMAT_GROUP vs inherited events seems difficult.
- */
 static void perf_output_read_group(struct perf_output_handle *handle,
 			    struct perf_event *event,
 			    u64 enabled, u64 running)
@@ -5769,6 +5766,12 @@ static void perf_output_read_group(struct perf_output_handle *handle,
 #define PERF_FORMAT_TOTAL_TIMES (PERF_FORMAT_TOTAL_TIME_ENABLED|\
 				 PERF_FORMAT_TOTAL_TIME_RUNNING)
 
+/*
+ * XXX PERF_SAMPLE_READ vs inherited events seems difficult.
+ *
+ * The problem is that its both hard and excessively expensive to iterate the
+ * child list from interrupt/NMI context.
+ */
 static void perf_output_read(struct perf_output_handle *handle,
 			     struct perf_event *event)
 {
@@ -9434,9 +9437,10 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
 	local64_set(&hwc->period_left, hwc->sample_period);
 
 	/*
-	 * we currently do not support PERF_FORMAT_GROUP on inherited events
+	 * We currently do not support PERF_SAMPLE_READ on inherited events.
+	 * See perf_output_read().
 	 */
-	if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))
+	if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ))
 		goto err_ns;
 
 	if (!has_branch_stack(event))

       reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170526205601.GA5271@tassilo.jf.intel.com>
2017-05-30  9:45 ` Peter Zijlstra [this message]
2017-05-30 13:57   ` Andi Kleen
2017-05-30 17:01     ` Peter Zijlstra
2017-05-30 17:55       ` Vince Weaver
2017-05-30 18:53         ` Peter Zijlstra
2017-05-31 21:08           ` Vince Weaver
2017-06-08  9:21   ` [tip:perf/core] perf/core: Correct event creation with PERF_FORMAT_GROUP tip-bot for Peter Zijlstra

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=20170530094512.dy2nljns2uq7qa3j@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vince@deater.net \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git