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]

Message-ID: <CABPqkBR4wNBmXTUKipmLK4dNFboEgHRMWby9q=Evg2_1dcwp3g@mail.gmail.com>
Date:	Mon, 2 Mar 2015 13:07:48 -0500
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <andi@...stfloor.org>
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>
Subject: Re: [PATCH V5 3/6] perf, x86: large PEBS interrupt threshold

On Mon, Mar 2, 2015 at 12:59 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> 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.
>
Not just in that case. In my test case, there is no re-jitting.
It is just that you need to reconcile the timestamps in the jit
meta-data file (jitdump)
and the perf.data so that you can insert the MMAP covering the jitted
code in the
right place. Otherwise the big anon mmap() remains in place and masks the MMAPs
generated from the jitdump. This is based on how my JIT patch series works.

>> 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.
>
You need to know that no parts of the address space is reused
overtime, i.e., no overlapping or recycled mmap regions.
--
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/