From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753984AbbBBRbW (ORCPT <rfc822;w@1wt.eu>);
	Mon, 2 Feb 2015 12:31:22 -0500
Received: from mx1.redhat.com ([209.132.183.28]:45444 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752080AbbBBRbV (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 2 Feb 2015 12:31:21 -0500
Date: Mon, 2 Feb 2015 18:30:51 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        LKML <linux-kernel@vger.kernel.org>, David Ahern <dsahern@gmail.com>,
        Andi Kleen <andi@firstfloor.org>,
        Stephane Eranian <eranian@google.com>,
        Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 14/42] perf record: Add --index option for building index
 table
Message-ID: <20150202173051.GG2241@krava.brq.redhat.com>
References: <1422518843-25818-1-git-send-email-namhyung@kernel.org>
 <1422518843-25818-15-git-send-email-namhyung@kernel.org>
 <20150201180635.GA6317@krava.brq.redhat.com>
 <54CF36AA.50508@intel.com>
 <20150202091554.GA1404@krava.brq.redhat.com>
 <54CF48DA.1050805@intel.com>
 <20150202100512.GA2241@krava.brq.redhat.com>
 <54CF687F.9090703@intel.com>
 <20150202121348.GE2241@krava.brq.redhat.com>
 <CAM9d7cgc0YAa+=N+x_F2uXtxtoL-a7+snChVfv4ggSAxoRR64Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAM9d7cgc0YAa+=N+x_F2uXtxtoL-a7+snChVfv4ggSAxoRR64Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 02, 2015 at 11:56:09PM +0900, Namhyung Kim wrote:
> Hi Jiri and Adrian,
> 
> On Mon, Feb 2, 2015 at 9:13 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Mon, Feb 02, 2015 at 02:07:27PM +0200, Adrian Hunter wrote:
> >
> > SNIP
> >
> >> >>
> >> >> Why not make it the same as all the other data. i.e. find the start and size
> >> >> via the index? And then just lump all the data together?
> >> >
> >> > thats what I suggested
> >>
> >> No, I meant really lump it all together. i.e. perf_file_header.data.size =
> >> total data size
> >>
> >> >
> >> >>
> >> >>> I guess we could workaround that by storing the 'perf_file_header::data'
> >> >>> as the last data section. That would require to treat it the same way as
> >> >>> all other data sections, but we could keep current header layout.
> >> >>
> >> >> Would it need to be last? Logically it should precede the data that depends
> >> >> on it.
> >> >
> >> > i suggested this as a workaround for having features at the end of the file
> >> > while keeping the current perf data header
> >>
> >> Which wouldn't be necessary if you lump it all together?
> >
> > yep, that's also an option
> 
> So we want a single section for the entire data area, right?
> 
> I also thought about it.  My concern was the holes between each data
> due to page alignment.  If an old tool which doesn't know about the
> index accesses to the data file, it'd just see a event type of 0 and
> stop processing.
> 
> Maybe the page alignment is not necessary?

seems ok,  but how about time ordering.. every time you reach new
file data you'll hit 'out of order event' right?

hum, maybe it's not a big deal now when it's just incrementing counter ;-)

jirka