[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBQkVvXzmyh6Q2yOTp9Ts5exSSp4A870DRAMWWpVvYYDig@mail.gmail.com>
Date: Thu, 12 Mar 2015 16:06:46 -0400
From: Stephane Eranian <eranian@...gle.com>
To: David Ahern <dsahern@...il.com>
Cc: Adrian Hunter <adrian.hunter@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Jiri Olsa <jolsa@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [BUG] perf report: ordered events and flushing bug
On Thu, Mar 12, 2015 at 3:53 PM, David Ahern <dsahern@...il.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists