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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 5 Aug 2014 07:17:33 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Stephane Eranian <eranian@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH 05/33] perf record: Allow the user to disable time stamps

> > 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.

> 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.

-Andi
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ