From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753794AbbCLJEs (ORCPT ); Thu, 12 Mar 2015 05:04:48 -0400 Received: from mga09.intel.com ([134.134.136.24]:17569 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753767AbbCLJEn (ORCPT ); Thu, 12 Mar 2015 05:04:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,387,1422950400"; d="scan'208";a="664183054" Message-ID: <55015634.6080101@intel.com> Date: Thu, 12 Mar 2015 11:02:44 +0200 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephane Eranian , LKML CC: Arnaldo Carvalho de Melo , Namhyung Kim , Jiri Olsa , David Ahern , Peter Zijlstra , "mingo@elte.hu" Subject: Re: [BUG] perf report: ordered events and flushing bug References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03/15 05:32, Stephane Eranian wrote: > Hi, > > I am working on the JIT support to improve the flow and have > perf record inject the MMAPs at the end of the collection. For > that I piggyback on the buildid pass. To avoid rewriting the entire perf.data > file, I simply append the the MMAP records at the end of the file. And that > puts them out-of-order in time systematically. But I thought it would be okay > because perf report would sort them by timestamps again. > > Well, it does not in all cases! Why? > > Because of the round flushing. Based on how far out-of-order an event is, > it may not be processed correctly because of round flushing. I believe this > may only impact MMAP records. This is a serious issue because > mmaps drive symbolization of samples. If samples are processed without the > proper dso mapping, then samples may not be symbolized or may be wrongly > symbolized. > > So far, the workaround I found was to set the oe->next_flush = 0 for > the ROUND mode. > In other words, do not flush anything until FINAL. To me, this is the > only sensible > way of avoiding this kind of problems. I am not sure I understand the > point of flushing > anyway, except to minimize memory footprint, maybe. But it does not > work with vastly > out-of-order mmaps. > > Do you have a better solution? You could hook the ordered event delivery (see Arnaldo's perf/core branch): if (tool->ordered_events) { inject->deliver = session->ordered_events.deliver; session->ordered_events.deliver = jit_mmap_deliver; } int jit_mmap_deliver(struct ordered_events *oe, struct ordered_event *event, struct perf_sample *sample) { struct perf_inject *inject = container_of(oe->tool, struct perf_inject, tool); if (next_jit_mmap_time < sample->time) { perf_session__deliver_synth_event(...); } return inject->deliver(oe, event, sample); } Need to get Arnaldo's comment on this approach first though.