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, 1 Nov 2013 10:47:13 +0100 From: Ingo Molnar <mingo@...nel.org> To: Chenggang Qin <chenggang.qin@...il.com>, Pekka Enberg <penberg@...nel.org>, Namhyung Kim <namhyung@...nel.org> Cc: linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...stprotocols.net>, Arjan van de Ven <arjan@...ux.intel.com>, Namhyung Kim <namhyung@...il.com>, Yanmin Zhang <yanmin.zhang@...el.com>, Wu Fengguang <fengguang.wu@...el.com>, Mike Galbraith <efault@....de>, Andrew Morton <akpm@...ux-foundation.org>, Chenggang Qin <chenggang.qcg@...bao.com> Subject: Re: [PATCH 0/4] perf report: add parameters 'start' & 'end' to specify analysis interval * Chenggang Qin <chenggang.qin@...il.com> wrote: > This patch set introduced a feature to analysis the samples in a specified time > interval. > After perf.data file was generated by perf record, the user could want to > analysis a sub time interval of the whole record period. > For some functions, the percent of its samples in a certain sub time interval is > different from the percent in the total record period. Showing the scene in a > certain time interval could allow users to more easily troubleshoot performance > problems. The sample's timestamp are recorded in the perf.data file. The samples > are sorted in the ordered_samples by timestamp while perf report processed them. > So, it is easily to search the samples whose timestamp are in a certain time > interval. > We add 2 paramters --start and --end to specify the time interval. > perf report --start xxxxx --end xxxxx > The smallest granularity of time interval is millsecond. > For example: > If the whole record period of a perf.data file is 10000 to 20000, we can use the > following command to analysis the samples between [15000, 16000). > perf report --start 15000 --end 16000 > The time is the uptime, it start timing from the system starts. > > Cc: David Ahern <dsahern@...il.com> > Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl> > Cc: Paul Mackerras <paulus@...ba.org> > Cc: Ingo Molnar <mingo@...hat.com> > Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net> > Cc: Arjan van de Ven <arjan@...ux.intel.com> > Cc: Namhyung Kim <namhyung@...il.com> > Cc: Yanmin Zhang <yanmin.zhang@...el.com> > Cc: Wu Fengguang <fengguang.wu@...el.com> > Cc: Mike Galbraith <efault@....de> > Cc: Andrew Morton <akpm@...ux-foundation.org> > Signed-off-by: Chenggang Qin <chenggang.qcg@...bao.com> > > Chenggang Qin (4): > perf tools: add parameter 'start' & 'end' to perf report > perf tools: relate 'start' & 'end' to perf_session > perf tools: record min_timestamp of samples queue in ordered_samples > perf tools: add the feature to assign analysis interval to perf > report > > tools/perf/builtin-report.c | 14 ++++++++++++ > tools/perf/util/session.c | 49 +++++++++++++++++++++++++++++++++++++++++- > tools/perf/util/session.h | 3 ++ > 3 files changed, 64 insertions(+), 2 deletions(-) Looks useful - but right now this has to be used 'blindly', without knowing _which_ portion of the perf.data is 'interesting'. That problem could be resolved by allowing direct manipulation of the start/end interval via the GTK front end: a small graph could show the 'sample graph', with two sliders specifying the reported interval? Something like this, at the top of the window: --------------------------------------------------------------- | | | .... ..... | | .. . ... . . | | . ... . . . . | | ..... .. .. .... .... .. | | [1] [2] | --------------------------------------------------------------- | | Usual perf report GTK output | | .... | The 'graph' might be anything that visualizes the time axis of the perf.data: a sample frequency visualization for example, or maybe a simple task activity graph based on fork/exec/exit data, with some simple time display included as well (a vertical marker every minute/second or so). The [1] and [2] markers demark the two sliders, which in the above mockup example show an 'interesting' portion of the profile with a lot of samples. With such a solution the feature you add would be very useful indeed, I'd even argue for the data file time-axis visualization to be enabled by default, with the initial start/end interval covering the whole perf.data, but the sliders being just a mouse-drag away from being changed. Thanks, Ingo -- 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