From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752760AbbBBO4f (ORCPT ); Mon, 2 Feb 2015 09:56:35 -0500 Received: from mail-oi0-f48.google.com ([209.85.218.48]:60267 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751489AbbBBO4a (ORCPT ); Mon, 2 Feb 2015 09:56:30 -0500 MIME-Version: 1.0 In-Reply-To: <20150202121348.GE2241@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> From: Namhyung Kim Date: Mon, 2 Feb 2015 23:56:09 +0900 X-Google-Sender-Auth: JOTi7vheAiw1yMlC7tRgtj9koMU Message-ID: Subject: Re: [PATCH 14/42] perf record: Add --index option for building index table To: Jiri Olsa Cc: Adrian Hunter , Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , LKML , David Ahern , Andi Kleen , Stephane Eranian , Frederic Weisbecker Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Maybe the page alignment is not necessary? Thanks, Namhyung