[BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[Stephane Eranian]

Hi,

I was looking at the sampling buffer format and I think there is an
issue in case
one samples on more than one event at a time and each event as a different
sample_type value (i.e., what it wants to record in each sample).

The sample_type is exported per-event by the API. In order to decode a sample
(PERF_RECORD_SAMPLE) one has to know which event caused it. To identify
the event, one has to include PERF_SAMPLE_ID in the sample_type. Each such
id uniquely identifies an event. Assuming the tool keeps a mapping of event to
ID, we can then reconstruct. This is what perf does.

The problem is that to extract the event ID, one has to already parse the sample
itself. That means, you need sample_type to extract the event ID.

Thus, we have a catch 22 situation.

Looking at the perf tool, it sort of works today simply because the
same sample_type
is applied to all events.

To solve this, we could either:
   - add the event ID to the header for PERF_RECORD_SAMPLE
   - enforce event ID is systematically saved at the beginning on
PERF_RECORD_SAMPLE

None of those options is transparent, I am afraid, unless we introduce
new record types.

Re: [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[Peter Zijlstra]

On Tue, 2011-04-19 at 19:10 +0000, Stephane Eranian wrote:
> Hi,
> 
> I was looking at the sampling buffer format and I think there is an
> issue in case
> one samples on more than one event at a time and each event as a different
> sample_type value (i.e., what it wants to record in each sample).
> 
> The sample_type is exported per-event by the API. In order to decode a sample
> (PERF_RECORD_SAMPLE) one has to know which event caused it. To identify
> the event, one has to include PERF_SAMPLE_ID in the sample_type. Each such
> id uniquely identifies an event. Assuming the tool keeps a mapping of event to
> ID, we can then reconstruct. This is what perf does.
> 
> The problem is that to extract the event ID, one has to already parse the sample
> itself. That means, you need sample_type to extract the event ID.
> 
> Thus, we have a catch 22 situation.
> 
> Looking at the perf tool, it sort of works today simply because the
> same sample_type
> is applied to all events.
> 
> To solve this, we could either:
>    - add the event ID to the header for PERF_RECORD_SAMPLE
>    - enforce event ID is systematically saved at the beginning on
> PERF_RECORD_SAMPLE
> 
> None of those options is transparent, I am afraid, unless we introduce
> new record types.

Or simply don't mix different sample_types in the same buffer?

Re: [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[Stephane Eranian]

On Tue, Apr 19, 2011 at 7:22 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2011-04-19 at 19:10 +0000, Stephane Eranian wrote:
>> Hi,
>>
>> I was looking at the sampling buffer format and I think there is an
>> issue in case
>> one samples on more than one event at a time and each event as a different
>> sample_type value (i.e., what it wants to record in each sample).
>>
>> The sample_type is exported per-event by the API. In order to decode a sample
>> (PERF_RECORD_SAMPLE) one has to know which event caused it. To identify
>> the event, one has to include PERF_SAMPLE_ID in the sample_type. Each such
>> id uniquely identifies an event. Assuming the tool keeps a mapping of event to
>> ID, we can then reconstruct. This is what perf does.
>>
>> The problem is that to extract the event ID, one has to already parse the sample
>> itself. That means, you need sample_type to extract the event ID.
>>
>> Thus, we have a catch 22 situation.
>>
>> Looking at the perf tool, it sort of works today simply because the
>> same sample_type
>> is applied to all events.
>>
>> To solve this, we could either:
>>    - add the event ID to the header for PERF_RECORD_SAMPLE
>>    - enforce event ID is systematically saved at the beginning on
>> PERF_RECORD_SAMPLE
>>
>> None of those options is transparent, I am afraid, unless we introduce
>> new record types.
>
> Or simply don't mix different sample_types in the same buffer?
>
Does the kernel disallow this when you merge the output via that ioctl()?

Re: [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[Stephane Eranian]

On Tue, Apr 19, 2011 at 9:20 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2011-04-19 at 21:16 +0000, Stephane Eranian wrote:
>> > Or simply don't mix different sample_types in the same buffer?
>> >
>> Does the kernel disallow this when you merge the output via that
>> ioctl()?
>
> No, it will happily comply and provide you with hard to parse output.
> Just don't do that if you're not willing to untangle it ;-)
But even if you wanted, you could not, that was my point.

>
>

Re: [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

[Peter Zijlstra]

On Tue, 2011-04-19 at 21:16 +0000, Stephane Eranian wrote:
> > Or simply don't mix different sample_types in the same buffer?
> >
> Does the kernel disallow this when you merge the output via that
> ioctl()? 

No, it will happily comply and provide you with hard to parse output.
Just don't do that if you're not willing to untangle it ;-)