poudriere(-devel) status -b %mem: based on sysctl's hw.availpages and on ->ki_p->ki_rssize (resident set size) [not on RAM+SWAP use]

poudriere's documentation is not explicit about which "memory" sizes that
the %mem is relative to. Nor is is explicit about how it gets the figure.

Tracing that "how" down lead to finding use of:

ps -ax -o jail,%cpu,%mem

(poudriere totals across the processes in the same jail [same builder].)

The ps documentation is in turn not explicit about such. Tracking that
down lead to:

/usr/main-src/bin/ps/print.c: fracmem = ((double)k->ki_p->ki_rssize) / mempages;
/usr/main-src/bin/ps/extern.h:extern unsigned long mempages;
/usr/main-src/bin/ps/nlist.c:unsigned long mempages; /* number of pages of phys. memory */
/usr/main-src/bin/ps/nlist.c: oldlen = sizeof(mempages);
/usr/main-src/bin/ps/nlist.c: if (sysctlbyname("hw.availpages", &mempages, &oldlen, NULL, 0) == -1)

So: poudriere status -b 's MEM% reports the (scaled) fraction:
(resident set size)/(hw.availpages)

It expects the processes in a jail to all have the same
hw.availpages value (a common denominator). It appears
to expect the same across jails in order to have
comparability across jails.

This implies that if one is trying to see relationships to
overall RAM+SWAP capacity, with a non-zero amount of SWAP
available in the context, the MEM% is inappropriate.

It would be good if the documentation indicated in some way
what to expect one can reasonably do with the MEM% figures
that "poudriere status -b" reports (vs. what one can not
reasonably do with them).

Note:
It would appear that the TMPFS figures reported are not part
of the resident set figures. So the MEM% figures look like
they exclude the TMPFS related RAM+SWAP usage figures that
are reported.

===
Mark Millard
marklmi at yahoo.com