[MOAB-dev] Measuring memory

[Jason Kraftcheck]

On 07/28/2010 02:24 PM, Steve Jackson wrote:
> This code snippet is duplicated several times in moab:
> 
> // estimate total program memory usage and store into tot_mem
> struct rusage r_usage;
> getrusage(RUSAGE_SELF, &r_usage);
> ...
> if( 0 != r_usage.ru_maxrss ){
>   tot_mem = r_usage.ru_idrss;
> }
> else{ 
>   // parse data from file /proc/self/stat
> }
> 
> This code is used to estimate memory usage in mbskin and mbperf, as well as in dagmc's ray_fire_test. 
> 
> This code is broken under Linux kernel 2.6.32, because under this kernel, getrusage() does report ru_maxrss, but does not report ru_idrss.  (Previous versions of the kernel reported neither value.)  See http://www.kernel.org/doc/man-pages/online/pages/man2/getrusage.2.html .  The result is that our tools always report a memory use of 0 with this kernel version.
> 

Checking memory usage is basically a non-portable mess.  Just getting the
code to compile on all platforms and return useful information on at least
those platforms that developers use is about the best that can be expected.


> Should this be fixed by changing the if statement to check for data in ru_idrss instead of ru_maxrss?  Or would a different approach be preferred? 

It is better to prefer the data from /proc/self/stat to that returned from
getrusage.  Not only is it more stable on Linux, it also contains more
useful information.  Using any 'rss' value is somewhat dubious if there is
any swapping going on on the system.  'vsize' from /proc/self/stat is
typically more informative.  Also, checking for support for /proc/self/stat
is a run-time test (no #ifdefs and such required.)  If the file open fails,
then it isn't supported.

E.g. lines 271-323 of tools/mbmem.cpp

Also, note that the values reported by getrusage for memory stats, if
reported, are the number of pages.  As page size can vary by architecture,
the code above looks non-portable (if not just plain wrong.)

> Also, ought we to move the get_time_mem function to a shared location, to reduce code duplication?

Maybe src/SysUtil.[ch]pp?

But if you do move it there, the time and mem functionality should be
separated.  I'm not sure that the time stuff even needs to be there because
things like clock() are quite portable.

- jason