From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933819AbbBCIo3 (ORCPT ); Tue, 3 Feb 2015 03:44:29 -0500 Received: from mga11.intel.com ([192.55.52.93]:38259 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753520AbbBCIo0 (ORCPT ); Tue, 3 Feb 2015 03:44:26 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,511,1418112000"; d="scan'208";a="671919743" Message-ID: <54D089F9.40309@intel.com> Date: Tue, 03 Feb 2015 10:42:33 +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: Jiri Olsa , Namhyung Kim CC: Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , LKML , David Ahern , Andi Kleen , Stephane Eranian , Frederic Weisbecker Subject: Re: [PATCH 14/42] perf record: Add --index option for building index table 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> <20150202173051.GG2241@krava.brq.redhat.com> In-Reply-To: <20150202173051.GG2241@krava.brq.redhat.com> 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 02/02/15 19:30, Jiri Olsa wrote: > 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 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. Please don't leave holes. Either fill them with a padding event or put the data end-to-end. >> >> 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 > >