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

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: <20150316011116.GN943@sejong>
Date:	Mon, 16 Mar 2015 10:11:16 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	David Ahern <dsahern@...il.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, acme@...nel.org
Subject: Re: [BUG] perf report: ordered events and flushing bug

Hi Arnaldo,

On Thu, Mar 12, 2015 at 05:50:53PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 12, 2015 at 04:06:46PM -0400, Stephane Eranian escreveu:
> > 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.
> 
> Right, Namhyung, do you keep all the MMAP records as well? Looking at
> the threaded patchkit I see:
> 
> -----------------
> [PATCH 23/38] perf tools: Add a test case for timed map groups handling
> 
> A test case for verifying thread->mg and ->mg_list handling during
> time change and new thread__find_addr_map_time() and friends.
> -----------------
> 
> You said:
> 
> Subject: [PATCH 19/37] perf tools: Introduce thread__find_addr_location_time() and friends
> 
> The *_time() variants are for find appropriate map (and symbol) at the
> given time.  This is based on the fact that map_groups list is sorted
> by time in the previous patch.
> ----------------
> 
> Running out of time here, but I couldn't find code where you keep
> 'struct map' that overlaps and that could then be looked up using
> timestamp in addition to the addr being looked up, that is needed for
> parallely process samples having first processed all PERF_RECORD_MMAP
> events.

It currently keeps only 'map_groups' per fork/exec so overlapped
'struct map' are not treated well assuming it's a rare event.  But
with the JIT map injection, it certainly also needs to keep 'struct
map' by timestamp - I'll work on it for the next spin.

Thanks,
Namhyung
--
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/