The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f4688fcd63165d4aaba3a42b46c287981bf9d79e

commit f4688fcd63165d4aaba3a42b46c287981bf9d79e
Author: Michael Lippautz <mlippautz@chromium.org>
Date: Wed Sep 12 14:14:48 2018

performance.memory: Allow values larger than 4GiB

In a world with site-isolation the values may not be quantized and precise
values may exceed 4GiB. This will get relevant once these counters also include
V8 external memory that is on a high-level tied to JS although technically
allocated on a different heap.

Bug: 883305
Change-Id: I70d12f73228302a6de6d5841c2cef995de1508f8
Reviewed-on: https://chromium-review.googlesource.com/1221246
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590664}
[modify] https://crrev.com/f4688fcd63165d4aaba3a42b46c287981bf9d79e/third_party/blink/renderer/core/timing/memory_info.idl

I'm trying to instrument a memory-intensive webapp that runs on machines out of my control. Users are performing tasks that can take from minutes to hours, and they seem to reload the page sometimes. The 20 minute limit on sample frequency makes it difficult to tell the performance of the page over time.

Could you lower the frequency limit to maybe 5 minutes? I would think the quantization already minimizes the utility for an attacker, but if not maybe you could compensate the higher frequency by randomly skewing the return value up or down a bucket or two?