All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kan.liang@intel.com, ak@linux.intel.com, eranian@google.com,
	vincent.weaver@maine.edu, tglx@linutronix.de, mingo@kernel.org,
	acme@redhat.com, jolsa@redhat.com,
	alexander.shishkin@linux.intel.com, ying.huang@linux.intel.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus
Date: Thu, 31 Mar 2016 11:44:39 -0300	[thread overview]
Message-ID: <20160331144439.GB27708@kernel.org> (raw)
In-Reply-To: <20160329120609.GG3408@twins.programming.kicks-ass.net>

Em Tue, Mar 29, 2016 at 02:06:09PM +0200, Peter Zijlstra escreveu:
> On Wed, Mar 23, 2016 at 11:24:37AM -0700, kan.liang@intel.com wrote:
> > The V2 patch is mainly based on Peter's suggestion. But I didn't rename
> > perf_event_aux to perf_event_sb. Because it looks there are many aux things
> > in the codes, e.g. AUX area in ring buffer. I'm not sure if we need to change
> > all aux to sb. We may do the rename later in separate patch.
> 
> Right.. no problem doing that in a separate patch.
> 
> > +static void perf_event_sb_mask(unsigned int sb_mask,
> > +			       perf_event_aux_output_cb output,
> > +			       void *data)
> > +{
> > +	int sb;
> > +
> > +	for (sb = 0; sb < sb_nr; sb++) {
> > +		if (!(sb_mask & (1 << sb)))
> > +			continue;
> > +		perf_event_sb_iterate(sb, output, data);
> > +	}
> > +}
> 
> > @@ -5852,7 +5910,8 @@ static void perf_event_task(struct task_struct *task,
> >  
> >  	perf_event_aux(perf_event_task_output,
> >  		       &task_event,
> > -		       task_ctx);
> > +		       task_ctx,
> > +		       (1 << sb_task) | (1 << sb_mmap) | (1 << sb_comm));
> >  }
> 
> So one side-effect of this change is that the above event can be
> delivered 3 times if you're 'lucky'.
> 
> Acme; does userspace care?

So, when processing a PERF_RECORD_FORK there is some sanity checks in
machine__process_fork_event() (tools/perf/util/machine.c), and one that
is affected by copies is:

        struct thread *thread = machine__find_thread(machine,
                                                     event->fork.pid,
                                                     event->fork.tid);
<SNIP>
        /* if a thread currently exists for the thread id remove it */
        if (thread != NULL) {
                machine__remove_thread(machine, thread);
                thread__put(thread);
        }

        thread = machine__findnew_thread(machine, event->fork.pid,
                                         event->fork.tid);
<SNIP>

So we conceivably may end up with multiple 'struct thread' pointing to
the same kernel thread, being held as references somewhere (in a
hist_entry, for instance, if a PERF_RECORD_SAMPLE happens mid sentence).

It probably will cope, but can't we just emit one single record?

PERF_RECORD_EXIT are ok:

int machine__process_exit_event(struct machine *machine, union perf_event *event,
                                struct perf_sample *sample __maybe_unused)
{
        struct thread *thread = machine__find_thread(machine,
                                                     event->fork.pid,
                                                     event->fork.tid);

        if (dump_trace)
                perf_event__fprintf_task(event, stdout);

        if (thread != NULL) {
                thread__exited(thread);
                thread__put(thread);
        }

        return 0;
}

PERF_RECORD_COMM will unecessarily add a new COMM to its list, leading tooling
to think that there was a prctl(PR_SET_NAME). This could conceivably be annoyed
away by checking if the "new" COMM is the current one, again, can't the kernel
emit just one record?

- Arnaldo

  parent reply	other threads:[~2016-03-31 14:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 18:24 [PATCH V2 1/1] perf/core: don't find side-band event from all pmus kan.liang
2016-03-29 12:06 ` Peter Zijlstra
2016-03-31 14:05   ` Liang, Kan
2016-03-31 14:25     ` acme
2016-03-31 14:44   ` Arnaldo Carvalho de Melo [this message]
2016-03-31 14:56     ` Peter Zijlstra
2016-03-31 16:21       ` Peter Zijlstra
2016-03-31 16:22         ` Peter Zijlstra
2016-04-06  8:09           ` Peter Zijlstra
2016-04-06 14:25             ` Liang, Kan
2016-05-12 13:30           ` Liang, Kan
2016-05-12 14:00             ` Peter Zijlstra
2016-06-03 10:49 ` [tip:perf/core] perf/core: Optimize side-band event delivery tip-bot for Kan Liang

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=20160331144439.GB27708@kernel.org \
    --to=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.weaver@maine.edu \
    --cc=ying.huang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.