lkml.org 
[lkml]   [2012]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 00/13] perf_events: add support for sampling taken branches (v3)
From
Hi,

The branch stack sampling patch exposes a flaw in the sampling
buffer format as currently exported by the kernel.

In the current format, sample records (RECORD_SAMPLE) are NOT
self-describing. That means that by looking at the fixed size header, it
is not possible to determine which event caused the sample to be recorded
and what's in the body of the variable length sample.

Such introspection is only possible once we know the event unique id
(PERF_SAMPLE_ID). But to get the event ID, we need to parse the
sample. But, given that a sample has a variable length, there is no
predefined position for that ID in the sample. You have a chicken
and egg problem here. There is no room left in the fixed size header
to fit this in.

This works today with perf because perf applies the SAME sample_type
to ALL events, i.e., all events have the same body layout. This is a limitation
of the tool. The kernel API clearly allows more flexibility but it is
hindered by
the problem I described above.

With branch sampling, this becomes more problematic because if you
are sampling on many events, it may not be necessary nor useful to capture
the branch sample stack for each event. With existing HW, the branch
stack uses at most 264 bytes in a sample. You'd be consuming the buffer
space much faster for nothing.

We need to solve this problem yet maintain backward compatibility with old
version of tools.

The kernel sampling buffer format needs to evolve to have fixed size header
that are more self-describing. The header somehow needs to contain the event
ID or the sample_type for type=RECORD_SAMPLE. I would prefer the former
because if we ever need more than 64-bits for sample_type, we would have the
same problem again. Having the event ID, requires that it be generated
systematically. That is not the case today.

That new buffer format could be requested, as a flag, when the event is created.
That would ensure backward compatibility.

An alternative would be to find a way to encode the event ID at a known position
somehow in the body of a RECORD_SAMPLE. But I don't see how that would be
possible (given there is already the sample_id_all stuff).

Any comments?


\
 
 \ /
  Last update: 2012-01-24 16:41    [W:0.199 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site