Em Tue, Aug 05, 2014 at 07:17:33AM -0700, Andi Kleen escreveu: > > > Time stamps are always implicitely enabled for record currently. The > > > old --time/-T option is a nop.
> > > Allow the user to disable timestamps by using --no-time > > > This can cause some minor misaccounting (by missing mmaps), but > > > significantly lowers the size of perf.data > > I'm not any big change in size: > > -rw------- 1 mingo mingo 384768 Aug 5 08:01 perf.data.timestamps > > -rw------- 1 mingo mingo 336952 Aug 5 08:00 perf.data.notimestamps > It will depend on your workload. What period did you use > (or did it automatically use) and what kind of > workload was it? > The smaller the period, the higher the benefit. > There are some classes of workloads where using a smaller > period is especially beneficial, essentially anything > with lots of small events, instead of long loops. > You also get a higher benefit if you use -c or -F, because > without that each sample is smaller (no period reported) > You also get higher benefit for longer traces, and traces > that do not start a lot of programs, as those > tend to be dominated by MMAP events and other overhead. I guess it would have been great if you had put the above paragraphs in the documentation for 'perf record' :-\ - Arnaldo > > So either remove the --time option altogether, or fix its > > 'misaccounting' so that the profile can be relied on. > I don't know how to fix it. Do you? > I guess one possible way to mitigate would be to lower the perf > buffer sizes, then the worst case out of ordering > would be less (I believe any potential problem > just comes from out of order events). However that may > impact performance. Mentioning that OOO is the main problem here, i.e. that some samples may be misaccounted, should've also been added to the documentation. - Arnaldo -- 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/
