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.

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.

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.

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

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.