Re: Support for Perf CTF traces now in master (was Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion)

[Jiri Olsa <jolsa@redhat.com>]

On Mon, Dec 01, 2014 at 12:28:08PM -0500, Jérémie Galarneau wrote:
> On Fri, Nov 28, 2014 at 6:26 AM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Wed, Nov 26, 2014 at 06:37:21PM +0100, Sebastian Andrzej Siewior wrote:
> >> * Alexandre Montplaisir | 2014-11-12 17:14:45 [-0500]:
> >
> > SNIP
> >
> >>
> >> >This was based on the most recent file format I was aware of, we will
> >> >update it accordingly if required.
> >> >
> >> >Testing welcome!
> >>
> >> I pushed the perf changes I mentioned to
> >>
> >>   git://git.breakpoint.cc/bigeasy/linux.git ctf_convert_7
> >>
> >
> > from perf data convert point of view (and libbabeltrace).. ;-)
> >
> > I tried to convert big perf.data (2GB) and my laptop got stuck
> > for few minutes.. the reason is that perf allocated too much memory
> >
> > I needed to add occasional bt_ctf_stream_flush into the
> > processing (patch attached)
> >
> > What I do now is checking if we processed given amount of events
> > for the stream and once the value is crossed I flush it.
> >
> > My question is if there's a way to find out the allocated memory
> > for the stream?  It'd be nicer to setup maximum allocation size
> > rather than the number of events.
> >
> 
> Not currently, although I agree that this would be a nice feature.
> Perhaps by setting a maximal packet size, CTF Writer could handle the
> automatic flushing.
> 
> Thoughts?

hum, it looks like 2 separated things to me.. the packet size is
result format related size.. I'm more interested in the size of
the 'struct ctf_stream' within the writer during the processing

it seems it wont be trivial to track this AFAICS from sources, but
I guess I can live so far with tracking the the number of events,
until we find something else

thanks,
jirka