linux-kernel - Re: [BUG] perf_event: semantic of PERF_SAMPLE

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] [day] [month] [year] [list]

Message-ID: <CABPqkBSsyrCF4NZhs_eHxhdZuCsJ1pXGkQ+T3HZR2GjghdY=_Q@mail.gmail.com>
Date:	Fri, 26 Aug 2011 16:02:16 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, mingo@...e.hu,
	Robert Richter <robert.richter@....com>,
	Vince Weaver <vweaver1@...s.utk.edu>
Subject: Re: [BUG] perf_event: semantic of PERF_SAMPLE_READ unclear

On Fri, Aug 26, 2011 at 2:13 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, 2011-08-26 at 14:02 +0200, Stephane Eranian wrote:
>> On Thu, Aug 25, 2011 at 7:32 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > On Thu, 2011-08-25 at 19:19 +0200, Stephane Eranian wrote:
>> >> But the difficulty is that
>> >> we cannot grab any locks, not sure we need one given the call path.
>> >
>> > Nah we should be able to simply iterate all siblings and update them
>> > in-place, since its group members they should all be co-scheduled. The
>> > only difficulty is cross pmu group members..
>> >
>> Are we allowing event from different PMU to be in the same event group?
>> If so, is that useful?
>
> We allow software events, which can always be scheduled, to be part of a
> hardware group. We don't allow mixing of different hardware pmus.
>
ok, good.

> Allowing a software event is useful if for example the hardware pmu
> doesn't have a sampling interrupt.
>
I think that's a good reason.

Now, there is something else I noticed when using PERF_SAMPLE_READ.
The libpfm4 example, task_smpl, shows the problem very easily.

$ task_smpl -e unhalted_core_cycles:period=2400000 noploop 1

IIP:0x0000000040062d PID:3658 TID:3658 TIME:19141370205834 STREAM_ID:1
PERIOD:2400000 ENA=979088465 RUN=979088465
	2330400873 unhalted_core_cycles:period=2400000

IIP:0x0000000040062d PID:3658 TID:3658 TIME:19141371213765 STREAM_ID:1
PERIOD:2400000 ENA=980096325 RUN=980096325
	2332800869 unhalted_core_cycles:period=2400000

IIP:0x0000000040062d PID:3658 TID:3658 TIME:19141372221662 STREAM_ID:1
PERIOD:2400000 ENA=981104225 RUN=981104225
	2335200869 unhalted_core_cycles:period=2400000

IIP:0x0000000040062d PID:3658 TID:3658 TIME:19141373229569 STREAM_ID:1
PERIOD:2400000 ENA=982112126 RUN=982112126
	2337600869 unhalted_core_cycles:period=2400000

Here each sample, capture the value of the sampling event. I would expect the
value to increase by at least the period (2400000) between two
consecutive samples.
The reality is: it's not always the case. It's close, though. For instance:

2332800869-2330400873 = 2399996

How to interpret this? Did the counter overflow before the period?

Is it that in the previous sample, it took a few cycles to stop the
PMU, i.e., the counter was not zero
when the PMU was stopped? And thus, when we add the period, we
actually come up with a shorter
effective period. I think the code that implements this is in
x86_perf_event_set_period().
--
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/