So this is the story, the semantic of "peak" is a bit ill defined, mostly my fault.
Originally we just had "peak" from Linux /proc/PID/status (or statm, whatever). The reason why we never introduce that check is because the Linux kernel API was guaranteeing that the peak was monotonic.

Later though I realized that I wasn't super happy about the peak semantic, especially for the browser process. Essentially one big peak would have completely hidden the others.
So we first make a kernel change to make the peak resettable (See  Issue 487961 ) and then changed the semantic of the peak in memory to be: "peak since the last dump, where supported by the kernel".
Essentially the deal is that the kernel updates the watermark in real time, so we would get any peak that did happen between one dump and the other.
This is why now the peak_resident is not making that check.

Anecdotally, we never made any big use of that "peak" column anyways, regardless of the semantics.

Having said this, we should perhaps revisit all this.
Once we'll introduce the CMM, that is going to be yet another blue column in memory-infra.
I think at that point we should hide by default some of the columns, otherwise on Linux people will get four different numbers:
Resident set
resident set (peak)
PSS
private_dirty
private footprint (from CMM)

which is going to be hyper confusing.

My choice would be to show only the CMM by default (private footprint and shared footprint), and have some UI option to expand and see the OS-level stats (private dirty & friends).


[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=695f055936938c674473ea071ca7359a863551e7