lkml.org 
[lkml]   [2011]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf: make perf.data more self-descriptive (v8)
On 18.12.11 20:49:42, Stephane Eranian wrote:
> On Dec 6, 2011 10:29 AM, "Robert Richter" <robert.richter@amd.com> wrote:
> >
> > On 05.12.11 11:24:05, Stephane Eranian wrote:
> > > The one thing I realized last week, is that all that header information,
> incl.
> > > the features bits do not seem to appear in the file perf.data file when you
> > > use the perf record pipe mode. We need to fix that otherwise, if you
> > > depend on information in those bits, it won't always be present. That's
> > > a major issue.
> >
> > Yes, this is because pipes are not seakable, which is necessary to
> > write the features.

> Yes, but we should have those headers regardless. They contain very useful info
> about the measurement. The seeks should not be required. The features can be at
> the end of data. We should not have to care how the perf.data file was created
> by the time we call perf report. Something looks broken to me here.

It must not necessarilly at the end of the file. Using lseek() makes
the implementation much more easy. If you have to write data
sequentially you must store later parts temporarilly in memory until
earlier parts are complete. E.g. you write a size value of null, write
all remaining data and then seek back to size to write the actuall
size.

I aggree, having the header information (or at least parts of it) not
in the pipe stream will cause some implications, such as that the
information get lost if piping through the network to a different
system.

We would have to rewrite large portions of the code to write data
without seeks.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center



\
 
 \ /
  Last update: 2011-12-19 10:29    [W:0.061 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site