On Fri, Dec 26, 2014 at 7:53 AM, Jiri Olsa <jo...@redhat.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
