Re: [BUG] perf report: ordered events and flushing bug

[Stephane Eranian]

On Thu, Mar 12, 2015 at 3:53 PM, David Ahern <dsahern@xxxxxxxxx> wrote:
> On 3/12/15 1:39 PM, Stephane Eranian wrote:
>>
>> What the point of having all the ordered event logic if you are saying
>> events
>> must be saved in order. I don't think there is a way to make that
>> guarantee
>> when monitoring multiple CPUs at the same time.
>
>
> The record command does not analyze the events, it just copies from mmap to
> file in lumps per mmap. e.g., on a given round the perf data file has events
> like this:
>
>    111112223344444444555566666F111111111
>    |<------- round --------->|^
>                               |
>         finished round event -|
>
> where 11111 are events read from mmap1, 2222 are events from mmap2, etc. F
> is the finished round event which a pass over all mmaps has been done.
>
> So for mmap1 all of the 11111 events are in time order, then jumping to
> mmap2 events the 2222 times are time sorted relative to mmap2 but not
> relative to mmap1 events.
>
> The ordered events code sorts the clumps into a time based stream:
>     123141641445124564234645656...
>
In my case I care about time ordering the mmap records between themselves
because they overlap on the address range.

t0: 0x100000-0x200000 //anon

t10: sample @ 0x100600
t20: sample @ 0x100250

t1: 0x100600-0x100700 jit2
t2: 0x100200-0x100300 jit3

with t1 < t2 < t2 < t10

I inject t1, t2 mmaps at the end of the perf.data file.

The full ordering should yield:

t0: 0x100000-0x200000 //anon
t1: 0x100600-0x100700 jit2
t2: 0x100200-0x100300 jit3
t10: sample @ 0x100600 -> jit2
t20: sample @ 0x100250 -> jit3

Partial ordering would likely yield both samples pointing to //anon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/