From: Adrian Hunter <adrian.hunter@intel.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Andi Kleen <andi@firstfloor.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 02/37] perf record: Use a software dummy event to track task/mmap events
Date: Tue, 30 Dec 2014 11:04:22 +0200 [thread overview]
Message-ID: <54A26A96.4080505@intel.com> (raw)
In-Reply-To: <20141230055111.GE6081@sejong>
On 30/12/14 07:51, Namhyung Kim wrote:
> Hi Adrian,
>
> On Mon, Dec 29, 2014 at 02:58:12PM +0200, Adrian Hunter wrote:
>> On 27/12/14 07:28, Namhyung Kim wrote:
>>> Hi David,
>>>
>>> On Sat, Dec 27, 2014 at 1:27 AM, David Ahern <dsahern@gmail.com> wrote:
>>>> On 12/24/14 12:14 AM, Namhyung Kim wrote:
>>>>>
>>>>> Prepend a software dummy event into evlist to track task/comm/mmap
>>>>> events separately. This is a preparation of multi-file/thread support
>>>>> which will come later.
>>>>
>>>>
>>>> Are you are making this the first event because of how perf internals are
>>>> coded -- that the first event tracks tasks events? With the tracking bit in
>>>> evsel you should not need to do that. Is there another reason?
>>>
>>> Yeah, I know the tracking bit can be set to any evsel in the evlist.
>>> But I'd like to keep it at a fixed index so that it can be easily
>>> identified at later stages (like perf report) too. Ideally, it'd be
>>> great if we have a way to distinguish this auto-added dummy tracking
>>> event from other (user-added) (dummy?) tracking events if any.
>>>
>>>>
>>>> ---8<---
>>>>
>>>>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>>>>> index cfbe2b99b9aa..72dff295237e 100644
>>>>> --- a/tools/perf/util/evlist.c
>>>>> +++ b/tools/perf/util/evlist.c
>>>>> @@ -193,6 +193,44 @@ int perf_evlist__add_default(struct perf_evlist
>>>>> *evlist)
>>>>> return -ENOMEM;
>>>>> }
>>>>>
>>>>> +int perf_evlist__prepend_dummy(struct perf_evlist *evlist)
>>>>> +{
>>>>> + struct perf_event_attr attr = {
>>>>> + .type = PERF_TYPE_SOFTWARE,
>>>>> + .config = PERF_COUNT_SW_DUMMY,
>>
>> Probably need .exclude_kernel = 1, here
>
> Ah, right.
>
>>
>>>>> + };
>>>>> + struct perf_evsel *evsel, *pos;
>>>>> +
>>>>> + event_attr_init(&attr);
>>>>> +
>>>>> + evsel = perf_evsel__new(&attr);
>>>>> + if (evsel == NULL)
>>>>> + goto error;
>>>>> +
>>>>> + /* use strdup() because free(evsel) assumes name is allocated */
>>>>> + evsel->name = strdup("dummy");
>>>>> + if (!evsel->name)
>>>>> + goto error_free;
>>>>> +
>>>>> + list_for_each_entry(pos, &evlist->entries, node) {
>>>>> + pos->idx += 1;
>>>>> + pos->tracking = false;
>>>>> + }
>>>>> +
>>>>> + list_add(&evsel->node, &evlist->entries);
>>>>> + evsel->idx = 0;
>>>>> + evsel->tracking = true;
>>>>
>>>>
>>>> perf_evlist__set_tracking_event()?
>>>
>>> I found that after I wrote this, so yes, it can use the function
>>> instead of the oped-code. But the loop traversal is needed anyway to
>>> fixup the evsel->idx.
>>
>> perf_evlist__set_tracking_event() also ensures there is only one tracking
>> event so it is easy to identify. It is the only event with attr->mmap etc
>> set to 1. Then you can use perf_evlist__add().
>
> Well, yes, I think we can put the dummy tracking event anywhere in the
> evlist with this, but I still slightly prefer put it at a fixed
> location for a possible code simplification..
Probably you should not be checking for the "tracking event" at all on the
processing side and instead just have perf report ignore all dummy events.
That generalizes things even more.
What is the code simplification?
next prev parent reply other threads:[~2014-12-30 9:06 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-24 7:14 [RFC/PATCHSET 00/37] perf tools: Speed-up perf report by using multi thread (v1) Namhyung Kim
2014-12-24 7:14 ` [PATCH 01/37] perf tools: Set attr.task bit for a tracking event Namhyung Kim
2014-12-31 11:25 ` Jiri Olsa
2014-12-24 7:14 ` [PATCH 02/37] perf record: Use a software dummy event to track task/mmap events Namhyung Kim
2014-12-26 16:27 ` David Ahern
2014-12-27 5:28 ` Namhyung Kim
2014-12-29 12:58 ` Adrian Hunter
2014-12-30 5:51 ` Namhyung Kim
2014-12-30 9:04 ` Adrian Hunter [this message]
2014-12-24 7:14 ` [PATCH 03/37] perf tools: Use perf_data_file__fd() consistently Namhyung Kim
2014-12-26 16:30 ` David Ahern
2014-12-27 5:30 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 04/37] perf tools: Add multi file interface to perf_data_file Namhyung Kim
2014-12-25 22:08 ` Jiri Olsa
2014-12-26 1:19 ` Namhyung Kim
2014-12-31 11:26 ` Jiri Olsa
2014-12-31 14:55 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 05/37] perf tools: Create separate mmap for dummy tracking event Namhyung Kim
2014-12-25 22:08 ` Jiri Olsa
2014-12-26 1:45 ` Namhyung Kim
2014-12-25 22:09 ` Jiri Olsa
2014-12-26 1:55 ` Namhyung Kim
2014-12-26 16:51 ` David Ahern
2014-12-27 5:32 ` Namhyung Kim
2014-12-29 13:44 ` Adrian Hunter
2014-12-30 5:57 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 06/37] perf tools: Introduce perf_evlist__mmap_multi() Namhyung Kim
2014-12-24 7:15 ` [PATCH 07/37] perf tools: Do not use __perf_session__process_events() directly Namhyung Kim
2014-12-31 11:33 ` Jiri Olsa
2014-12-24 7:15 ` [PATCH 08/37] perf tools: Handle multi-file session properly Namhyung Kim
2014-12-31 12:01 ` Jiri Olsa
2014-12-31 14:53 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 09/37] perf record: Add -M/--multi option for multi file recording Namhyung Kim
2014-12-24 7:15 ` [PATCH 10/37] perf report: Skip dummy tracking event Namhyung Kim
2014-12-24 7:15 ` [PATCH 11/37] perf tools: Introduce thread__comm_time() helpers Namhyung Kim
2014-12-26 17:00 ` David Ahern
2014-12-27 5:36 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 12/37] perf tools: Add a test case for thread comm handling Namhyung Kim
2014-12-24 7:15 ` [PATCH 13/37] perf tools: Use thread__comm_time() when adding hist entries Namhyung Kim
2014-12-25 22:53 ` Jiri Olsa
2014-12-26 2:10 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 14/37] perf tools: Convert dead thread list into rbtree Namhyung Kim
2014-12-25 23:05 ` Jiri Olsa
2014-12-26 2:26 ` Namhyung Kim
2014-12-26 17:14 ` David Ahern
2014-12-27 5:42 ` Namhyung Kim
2014-12-27 15:31 ` David Ahern
2014-12-28 13:24 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 15/37] perf tools: Introduce machine__find*_thread_time() Namhyung Kim
2014-12-27 16:33 ` David Ahern
2014-12-28 14:50 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 16/37] perf tools: Add a test case for timed thread handling Namhyung Kim
2014-12-31 14:17 ` Jiri Olsa
2014-12-31 15:32 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 17/37] perf tools: Maintain map groups list in a leader thread Namhyung Kim
2014-12-24 7:15 ` [PATCH 18/37] perf tools: Remove thread when map groups initialization failed Namhyung Kim
2014-12-28 0:45 ` David Ahern
2014-12-29 7:08 ` Namhyung Kim
2014-12-24 7:15 ` [PATCH 19/37] perf tools: Introduce thread__find_addr_location_time() and friends Namhyung Kim
2014-12-24 7:15 ` [PATCH 20/37] perf tools: Add a test case for timed map groups handling Namhyung Kim
2014-12-24 7:15 ` [PATCH 21/37] perf tools: Protect dso symbol loading using a mutex Namhyung Kim
2014-12-24 7:15 ` [PATCH 22/37] perf tools: Protect dso cache tree using dso->lock Namhyung Kim
2014-12-24 7:15 ` [PATCH 23/37] perf tools: Protect dso cache fd with a mutex Namhyung Kim
2014-12-24 7:15 ` [PATCH 24/37] perf session: Pass struct events stats to event processing functions Namhyung Kim
2014-12-24 7:15 ` [PATCH 25/37] perf hists: Pass hists struct to hist_entry_iter functions Namhyung Kim
2014-12-24 7:15 ` [PATCH 26/37] perf tools: Move BUILD_ID_SIZE definition to perf.h Namhyung Kim
2014-12-24 7:15 ` [PATCH 27/37] perf report: Parallelize perf report using multi-thread Namhyung Kim
2014-12-24 7:15 ` [PATCH 28/37] perf tools: Add missing_threads rb tree Namhyung Kim
2014-12-24 7:15 ` [PATCH 29/37] perf top: Always creates thread in the current task tree Namhyung Kim
2014-12-24 7:15 ` [PATCH 30/37] perf tools: Fix progress ui to support multi thread Namhyung Kim
2014-12-24 7:15 ` [PATCH 31/37] perf record: Show total size of multi file data Namhyung Kim
2014-12-24 7:15 ` [PATCH 32/37] perf report: Add --multi-thread option and config item Namhyung Kim
2014-12-24 7:15 ` [PATCH 33/37] perf tools: Add front cache for dso data access Namhyung Kim
2014-12-24 7:15 ` [PATCH 34/37] perf tools: Convert lseek + read to pread Namhyung Kim
2014-12-24 7:15 ` [PATCH 35/37] perf callchain: Save eh/debug frame offset for dwarf unwind Namhyung Kim
2014-12-24 7:15 ` [PATCH 36/37] perf tools: Add new perf data command Namhyung Kim
2014-12-24 7:15 ` [PATCH 37/37] perf data: Implement 'split' subcommand Namhyung Kim
2014-12-24 13:51 ` Arnaldo Carvalho de Melo
2014-12-24 14:14 ` Namhyung Kim
2014-12-24 14:45 ` Arnaldo Carvalho de Melo
2014-12-26 13:59 ` Jiri Olsa
2014-12-27 5:21 ` Namhyung Kim
2014-12-26 14:02 ` [RFC/PATCHSET 00/37] perf tools: Speed-up perf report by using multi thread (v1) Jiri Olsa
2014-12-27 5:23 ` Namhyung Kim
2015-01-05 18:48 ` Andi Kleen
2015-01-06 15:50 ` Stephane Eranian
2015-01-07 7:13 ` Namhyung Kim
2015-01-07 15:14 ` Stephane Eranian
2015-01-08 5:19 ` Namhyung Kim
2015-01-07 6:58 ` Namhyung Kim
2015-01-08 14:52 ` Andi Kleen
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=54A26A96.4080505@intel.com \
--to=adrian.hunter@intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
/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