linux-kernel - Re: [PATCH V5 3/6] perf, x86: large PEBS interrupt threshold

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:	Mon, 2 Mar 2015 18:59:28 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Kan Liang <kan.liang@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH V5 3/6] perf, x86: large PEBS interrupt threshold

> At more reasonable periods, the benefit seems to vanish. I don't quite know
> of a scenario where one would absolutely need very small period. This is
> about statistical sampling and not tracing.

In workloads with small irregular events (e.g. irregularly
space event handlers that run for less than a milli-second) a small
period is the only reliable way to catch them.

You're right the mode is not very useful for anything
that runs the same code continuously.

However irregular scenarios are becoming more and more
important. For example this is useful for characterizing
complex GUI applications.

> I believe that you need to know exactly what you are doing, i.e., what you
> are measuring for this improvement to make a difference and yet provide
> useful data. I believe in system-wide mode, the benefit vanishes quickly
> because you may not know in advance what you are measuring. The
> key problem is the lack of timestamp which help order the MMAP records
> vs. sample records.  I tried with my recently released Jitted code patch
> series and sure enough with the --no-time, you cannot correlate samples
> to symbols in the jitted code anymore. This is a case where you need
> the timestamps to synchronize user level sampling data (obtained from
> the jit compiler) with perf samples. Unless I know I am measuring jitted
> code, I would not be able to use the PEBS buffer improvements without
> losing symbolization capabilities.

This is only when the JIT regularly reuses virtual address space.
If it mostly uses new addresses there is no issue, as the
mappings are unique. I believe JITs rarely reuse.

> Overall, I think the patch is only useful to a small set of monitoring scenarios
> and for people using "extreme" sampling periods. It requires the user to be
> aware of the behavior of the monitoring app (because of the no-timestamp
> requirement).

Yes right now with all the limitations you need to know
what you're doing. However it's still useful for experts.

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