From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753281AbbCLIDY (ORCPT ); Thu, 12 Mar 2015 04:03:24 -0400 Received: from lgeamrelo01.lge.com ([156.147.1.125]:40076 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751857AbbCLIDT (ORCPT ); Thu, 12 Mar 2015 04:03:19 -0400 X-Original-SENDERIP: 10.177.220.203 X-Original-MAILFROM: namhyung@kernel.org Date: Thu, 12 Mar 2015 16:57:39 +0900 From: Namhyung Kim To: Stephane Eranian Cc: LKML , Arnaldo Carvalho de Melo , Jiri Olsa , David Ahern , Peter Zijlstra , "mingo@elte.hu" Subject: Re: [BUG] perf report: ordered events and flushing bug Message-ID: <20150312075739.GK943@sejong> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 Stephane, On Wed, Mar 11, 2015 at 11:32:15PM -0400, 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 may want to see my multi-thread work [1] for this. It supports out-of-time processing of samples by splitting metadata and samples with index. I think you can just inject the MMAPs to the metadata area - yes, it requires whole file rewrite anyway but you can skip the sample data parts. [1] https://lkml.org/lkml/2015/3/2/988 Thanks, Namhyung