Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for smaps_rollup #219

Closed
amete opened this issue Apr 27, 2022 · 3 comments · Fixed by #234
Closed

Add support for smaps_rollup #219

amete opened this issue Apr 27, 2022 · 3 comments · Fixed by #234
Assignees
@amete
Labels
enhancement New feature or request
Milestone
v3.1

Comments

@amete
Copy link
Collaborator

amete commented Apr 27, 2022

Hi @graeme-a-stewart,

Arguably one of the most expensive operations we do is traversing through smaps to get an accurate measurement of pss. It seems as if the "newer" kernel version have a new file, called /proc/[pid]/smaps_rollup, that provides pre-summed memory information for a given process. It looks to be a very convenient way to simply read the pss measurement rather than reading/summing everything by-hand. We can probably add support for it some time soon (i.e. use it if it's available). What do you think?

Best,
Serhan
@amete amete added the enhancement New feature or request label Apr 27, 2022
@amete amete self-assigned this Apr 27, 2022
@graeme-a-stewart
Copy link
Member

Hi @amete - oh, it would be an excellent idea. When we looked the majority of prmon's cycles were going to smaps parsing, so if it can be done more efficiently all the better.

@amete
Copy link
Collaborator Author

amete commented Jun 1, 2022

Thanks a lot @graeme-a-stewart .

Actually, the "rolled up" version doesn't seem to be a 1-1 replacement since it seems to be missing the Size (which is what we use for vmem), at least on CentOS 8 e.g.:

$ cat /proc/self/smaps_rollup
564007177000-7ffdb8b80000 ---p 00000000 00:00 0                          [rollup]
Rss:                1912 kB
Pss:                 194 kB
Shared_Clean:       1768 kB
Shared_Dirty:          0 kB
Private_Clean:        32 kB
Private_Dirty:       112 kB
Referenced:         1912 kB
Anonymous:           112 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
FilePmdMapped:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB

I'm not sure why it's not there since the original proposal clearly includes it. Having said that, we can still get this from /proc/[pid]/statm(status). It'll cost us an extra open/close but considering how large smaps gets for applications such as full reconstruction jobs it might still be beneficial.

@graeme-a-stewart
Copy link
Member

At least it would be worth trying - we can implement it and then do a comparison between resources consumed in the two the versions. I suppose it's only available for newer kernels, so we'd need to fall back to the older parser if there's no rollup file.

@graeme-a-stewart graeme-a-stewart added this to the v3.1 milestone Jun 23, 2023
@amete amete mentioned this issue Aug 3, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@amete amete

Labels
enhancement New feature or request
Projects
None yet
Milestone
v3.1
Development

Successfully merging a pull request may close this issue.

Add support for fast memory monitoring using smaps_rollup HSF/prmon
2 participants
@amete @graeme-a-stewart