+ How many calls a process made, not only how many bytes it moved

[Hawkynt]

Bytes moved and calls made are different questions, and a process can be heavy in one and light in
the other: a program reading a gigabyte in one call and one reading it a byte at a time cost the
machine very different amounts, and only the call count tells them apart. Read and write operations,
their deltas, the other-operation count and the I/O wait all come from lines of /proc/[pid]/io the
row was already opening and not reading.

The shareable working set comes from the same read as the private half rather than a second one, so
the two halves cannot disagree about the file they were read from. It is the resident memory somebody
else could also be holding — what a file backs plus what a shared segment does — which is the part
that does not come back when the process exits.

Held against this machine: syscr and syscw match the operation counts to the digit, and RssFile plus
RssShmem match the shareable set to the byte.

Recovered from a session that stopped mid-sentence on exactly that last point. It built clean and the
suite was green as found; the tests are mine, since it had not reached them — including the one that
matters, that a process whose io could not be read says so rather than reporting no calls at all.

Measured rather than assumed: interleaved against main in both orders, the settled rounds are 55-58
ms per thousand processes on main and 57-58 on this branch. The CPU gate is over its ceiling in that
run — and main measured 104 ms in the same run, so it is over for both, which is the situation the
benchmark's own comment already describes. The allocation budget, which is the one that would catch
a per-process cost, is unchanged at 203 bytes.