linux-kernel - Re: [PATCH 14/42] perf record: Add --index option for building index table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2015 18:30:51 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Stephane Eranian <eranian@...gle.com>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 14/42] perf record: Add --index option for building index
 table

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@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/