lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 26 Dec 2014 11:10:33 +0900 From: Namhyung Kim <namhyung@...nel.org> To: Jiri Olsa <jolsa@...hat.com> Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, LKML <linux-kernel@...r.kernel.org>, David Ahern <dsahern@...il.com>, Stephane Eranian <eranian@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, Andi Kleen <andi@...stfloor.org>, Frederic Weisbecker <fweisbec@...il.com> Subject: Re: [PATCH 13/37] perf tools: Use thread__comm_time() when adding hist entries On Fri, Dec 26, 2014 at 7:53 AM, Jiri Olsa <jolsa@...hat.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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists