Add support for fast memory monitoring using smaps_rollup #234
Conversation
There was a problem hiding this comment.
There's one minor problem with the get_longopts that's trivial.
My larger concern is that when you switch this option on the reported vmem is 0. That's just wrong and I don't like using 0 as a magic value that means sorry, we couldn't measure this.
My proposal is that we'd rather drop that value from the reported statistics, which would be less confusing. Plus, that definitely needs documentation!
|
Wow, I didn't realize this slipped through the cracks for so long @graeme-a-stewart 😄 Thanks a lot for the review. I tweaked the implementation in that if a particular metric is not available, we print a warning message and drop it from the list of monitored metrics. I also fixed the typo in the options. How does this look from a functional point of view? If it looks OK, I can put together a few words in the README for the new functionality and we can probably push this through. Please let me know, many thanks. |
There was a problem hiding this comment.
Hi @amete - this is looking good now. I only have one code suggestion (downgrade the warning to info). And the README will need to be updated.
|
Thanks a lot @graeme-a-stewart. I just pushed a new version. Can you let me know how this looks, please? |
This PR adds the so-called fast memory monitoring option, which uses the
smaps_rollupfile instead of the standardsmapsfile, as discussed in #219.There are some limitation though. Most notably the
Sizemetric is missing in the pre-summed file, where we get the virtual memory measurements, and the fact thatsmaps_rollupis not supported by some older kernels, e.g.,cc7. Therefore, we probably need to do a little bit of testing before using this new mode for anything serious.Closes #219