This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v2 1/2] [CLEANUP] perf-probe: Expand given path to absolute path
- From: Arnaldo Carvalho de Melo <acme at ghostprotocols dot net>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: David Ahern <dsahern at gmail dot com>, Ingo Molnar <mingo at kernel dot org>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, lkml <linux-kernel at vger dot kernel dot org>, "Steven Rostedt (Red Hat)" <rostedt at goodmis dot org>, Oleg Nesterov <oleg at redhat dot com>, "David A. Long" <dave dot long at linaro dot org>, systemtap at sourceware dot org, yrl dot pp-manager dot tt at hitachi dot com, Namhyung Kim <namhyung at kernel dot org>
- Date: Fri, 27 Dec 2013 16:25:30 -0300
- Subject: Re: [PATCH -tip v2 1/2] [CLEANUP] perf-probe: Expand given path to absolute path
- Authentication-results: sourceware.org; auth=none
- References: <20131226054148 dot 22364 dot 25224 dot stgit at kbuild-fedora dot novalocal> <20131226054150 dot 22364 dot 12187 dot stgit at kbuild-fedora dot novalocal> <52BC39D6 dot 3090908 at gmail dot com> <20131226142248 dot GE30980 at ghostprotocols dot net> <52BD1ACA dot 7030506 at hitachi dot com> <52BD8C9B dot 8030206 at gmail dot com> <20131227174902 dot GA13381 at ghostprotocols dot net>
Em Fri, Dec 27, 2013 at 02:49:02PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Dec 27, 2013 at 09:20:11AM -0500, David Ahern escreveu:
> > On 12/27/13, 1:14 AM, Masami Hiramatsu wrote:
> > >Nowhere, since there is no terminal code for user
> > >command interface.
>
> > >Those memories are released when the program terminated.
> > >I think it is just a waste of the time to free the memory
> > >pieces which are not used(and allocated) repeatedly.
> > >Or, is there any chance to call this part directly from
> > >other command?
>
> There is always the chance of parts of a tool to be librarized, I think
> the rule is: allocator -> lifetime -> destructor, explicit.
>
> We may want to explicitely disable some big destructor call (or lots of
> destructors, like symbols + hists, etc) because it may make exit time to
> be overly long, but at least we'll know what destructors to call when
> such code gets librarized.
Having said that, I applied the current patch, as it doesn't makes
things much worser than they already are, i.e. we need to audit that
code further, and these patches provided an useful new functionality.
- Arnaldo