Page MenuHomeFreeBSD

procstat: vm: add shared pages and page totals
Needs ReviewPublic

Authored by kevans on Mon, Nov 22, 6:10 PM.

Details

Reviewers
kib
markj
Group Reviewers
manpages
Summary

Used for some downstream diagnostics. A spare is taken for shared pages
to avoid size/layout discrepancies between i386/amd64 due to padding.

X-NetApp-PR: #68

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 42919
Build 39807: arc lint + arc unit

Event Timeline

sys/kern/kern_proc.c
2628

I do not understand what is the semantic of kve_shared_resident. For instance it reports non-zero count for an object on top of shadow chain, which can have single mapping. On the other hand, the object at the bottom of shadow chain, which is probably _the_ shared mapping, is reported as having private resident pages.

That said, sysctl vm.vm_objects already returns backing_object handle. The only issue with this sysctl is that it returns huge amount of information and thus is often slow.

sys/kern/kern_proc.c
2628

I'm still probing them to figure out what they were really looking for, but the gist of what I've gathered from previous iterations and reviews is that I /think/ they were wanting the full extent of any mmap'd region, so lobj->resident_page_count. It looks like the general idea was that they wanted to be able to identify potential pain points, large mappings that may suddenly explode our memory usage if we started scribbling all over them.

By that token, I think we would want file mappings as well, but I think I do see a caveat based on our out-of-band discussion about it yesterday (and some light reading of vmspace_fork(), hopefully between the two I have a complete understanding here)... the mapping in the parent post-fork presumably points to an object with a backing object that would then appear as shared, but I don't think that's what you want.

sys/kern/kern_proc.c
2628

What is 'full extent of a mmapped region' ? How does it relate to the number of resident pages in the lowest object (the start of the shadow chain)?

So I do not understand still, what is the idea there.

sys/kern/kern_proc.c
2628

Size of the original mapping, which is presumably the size of the start of the shadow chain

sys/kern/kern_proc.c
2628

Size of the object is unrelated to the size of the mapping, it may be smaller or larger. And resident_page_count is unrelated to the object size.