would be nice to report memory use through Oximeter

similar to but i imagine much simpler than my sibling issue against propolis.

i've talked with @faithanalog a bit and it seems like if we reported both downstairs RSS and allocated address space. the difference here can be read as roughly the difference between peak memory use and "current", though if we had max RSS (illumos issue for that one) we'd know how much more memory is requested for heap that we never actually use.

collecting this today, in the case of instantaneous RSS and swap charges, is possible via pmap and friends, and i've at least got an example of collecting it programmatically here. but this can introduce pretty significant delays and would definitely result in weird perf issues for customers.

so, while it would be nice to report through Oximeter, it might not be desirable today given the expected probe effect.

my thinking for Propolis is that we could have the code to collect this stuff in-tree, behind an API that's not used by the control plane, but we can query on dogfood or racklettes where more understanding of the potential hiccups that measuring can introduce

might call this a more detailed phrasing of https://github.com/oxidecomputer/crucible/issues/364 ? helps with https://github.com/oxidecomputer/crucible/issues/604 ?

Start by reviewing the linked Propolis issue 890, Crucible issues 364 and 604, and the referenced Propolis memory-stats example. Determine whether RSS and allocated address space can be collected without unacceptable probe effects, then define the Oximeter integration and measurement behavior that would count as done.