Re: [PATCH 13/37] perf tools: Use thread__comm_time() when adding hist entries

[Namhyung Kim]

On Fri, Dec 26, 2014 at 7:53 AM, Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> On Wed, Dec 24, 2014 at 04:15:09PM +0900, Namhyung Kim wrote:
>
> SNIP
>
>>
>>                       he = __hists__add_entry(hists, &al, NULL,
>> -                                             NULL, NULL, 1, 1, 0, true);
>> +                                             NULL, NULL, 1, 1, 0, -1, true);
>>                       if (he == NULL)
>>                               goto out;
>>
>> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
>> index 9314286ed25c..d322264bac22 100644
>> --- a/tools/perf/util/hist.c
>> +++ b/tools/perf/util/hist.c
>> @@ -451,11 +451,11 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
>>                                     struct branch_info *bi,
>>                                     struct mem_info *mi,
>>                                     u64 period, u64 weight, u64 transaction,
>> -                                   bool sample_self)
>> +                                   u64 timestamp, bool sample_self)
>>  {
>>       struct hist_entry entry = {
>>               .thread = al->thread,
>> -             .comm = thread__comm(al->thread),
>> +             .comm = thread__comm_time(al->thread, timestamp),
>
> with thread object having multiple comm entries, could this hurt
> the single threaded performance?

Probably.  But in my test, the single threaded performance on a single
data file is slightly better or almost same.  I didn't investigate it
yet where the performance gain comes, but anyway, I think this has
almost no effect on the performance since most thread will have just
one or two comms I guess.

And JFYI, the single threaded performance on a multi-file data is
better (I tested same data using 'perf data split' command and no
--multi-thread option to perf report) as IMHO it doesn't need to use
the ordered event queue layer.

>
> The thread__comm_time function iterates comm_list each time,
> maybe you could add some 'last_comm found check' logic in it?

I think it can be easily added later if it really affects the performance.

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