[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBQm2oKzTES8VSai-O9G9Ag1TzZZznR2wEHeWouRY3ZrXQ@mail.gmail.com>
Date: Wed, 23 May 2012 15:06:44 +0200
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
mingo@...e.hu
Subject: Re: [PATCH v2 4/5] perf record: add meta-data support for pipe-mode
On Wed, May 23, 2012 at 10:21 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, 2012-05-22 at 19:51 +0200, Stephane Eranian wrote:
>> The problem is that the headers as they are written to the file need
>> seeking in the file to update the offset table. That is NOT possible when
>> you operate in pipe mode.
>
> I know that, I said as much. But it is quite possible to multiplex
> streams without the need for seeking, look at these MKV containers that
> contain video, multiple-audio and multiple-subtitle tracks.
>
> The fact is, whomever wrote that pipe mode took a bonghit before
> touching the keyboard. They didn't even ask if we could reserve a range
> for userspace events, let alone consider if it was a good idea to begin
> with.
You're probably right, but the fact of the matter is, it's there now and
we have lots of perf.data piling up all over the place. So you need
to maintain compatibility with those. In my patch, I am just extending
what's already there. I was not trying to rewrite the whole pipe mode + meta
data logic (though I have done some of that already in the past).
Clearly pipe-mode was an after thought, but it is useful, I know people who
use it. Obviously I use it, otherwise I would not necessarily have spent the
time fixing the meta-data headers.
But I think, for the time being, my patch addresses an issue and does
not prevent us for discussing a new file format for perf record, I have nothing
against that.
>
> If we ever manage to get splice() working you can't keep that pipe mode
> working anyway.
>
> Pushing everything over a single stream isn't a scalable solution anyway
> in the same way that writing everything into the one file isn't the best
> thing and would ideally be replaced as well.
--
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/
Powered by blists - more mailing lists