Messages in this thread | | | Date | Mon, 1 Dec 2014 21:44:28 +0100 | From | Jiri Olsa <> | Subject | Re: Support for Perf CTF traces now in master (was Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion) |
| |
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
| |