From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752108AbbCPBQm (ORCPT ); Sun, 15 Mar 2015 21:16:42 -0400 Received: from lgeamrelo01.lge.com ([156.147.1.125]:46438 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751475AbbCPBQl (ORCPT ); Sun, 15 Mar 2015 21:16:41 -0400 X-Original-SENDERIP: 10.177.220.203 X-Original-MAILFROM: namhyung@kernel.org Date: Mon, 16 Mar 2015 10:11:16 +0900 From: Namhyung Kim To: Arnaldo Carvalho de Melo Cc: Stephane Eranian , David Ahern , Adrian Hunter , LKML , Jiri Olsa , Peter Zijlstra , Ingo Molnar , acme@kernel.org Subject: Re: [BUG] perf report: ordered events and flushing bug Message-ID: <20150316011116.GN943@sejong> References: <55015634.6080101@intel.com> <5501E54C.2090107@gmail.com> <5501EA45.8080608@gmail.com> <5501EEB9.8000705@gmail.com> <20150312205053.GC2301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150312205053.GC2301@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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