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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150312205053.GC2301@redhat.com>
Date:	Thu, 12 Mar 2015 17:50:53 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	David Ahern <dsahern@...il.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Namhyung Kim <namhyung@...nel.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

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.




 
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ