On Mon, Apr 28, 2014 at 2:37 PM, Andrew Stitcher <[email protected]>wrote:
> On Mon, 2014-04-28 at 13:34 -0400, Alan Conway wrote: > > I wouldn't instrument the code for this, there are tools that can > > measure this kind of thing without code changes. > > > > valgrind has cachegrind which profiles calls in general and can be used > > to identify the sources of malloc calls - there's a nice visualization > > tool kcahcegrind for looking at the output. > > > > valgrind also has a memory profiler called massif which I haven't really > > used. > > > > systemtap provides a general scripting language that you can use to > > intercept malloc calls. There are a bunch of memory related scripts > > pre-packaged > > http://sourceware.org/systemtap/examples/keyword-index.html#MEMORY > > > > There are surely others... > > These are great tools that work really well and I've enjoyed using them > myself on big heavy weight platforms like Linux. However on the little > embedded platforms the OP was asking about there is no real alternative > but to use something much lighter weight. For example some simple built > in instrumentation. Perhaps built in to the linked-in libc runtime > library though so it needn't necessarily require code changes to Proton. > > Of course if you can run the initial scenario on Linux under > valgrind/systemtap etc. first then that will give you an idea what you > need to go and change, but you will still need the target machine > instrumentation in the end. > I'd also like to be able to track peak memory usage as well as mallocs/frees under various load scenarios, and I suspect valgrind would add too much overhead for that. --Rafael
