Follows up from internal thread "Can we trace "swapping activity"? "

Copy/pasting relevant comments in the discussion:

primiano@
On Linux/Android I am 90% confident this is doable by just reading /proc/self/stat, specifically this field:
 (12) majflt  %lu
                        The number of major faults the process has made
                        which have required loading a memory page from disk.
See http://man7.org/linux/man-pages/man5/proc.5.html

Reading /proc/self/stat itself might not be too straightforward because of the sandbox. On Linux Desktop the renderer cannot open() anything at all because of the BPF sandbox, but the browser process can open renderers' pseudo files. On Android the bpf-sandbox (enabled only on 64 bit) allows open() (required by the in-process components of the android runtime) but the browser cannot open renderer's process pseudo files because of the UID isolation.
Nothing really new for us (memory-infra) but something to keep in mind. We have some workarounds already in place to get around this sandboxing weirdeness (+ssid who is just seen this for the peak detection that has exactly the same problem).

On Windows I guess there is something query-able via PdhOpenQuery / AddPdhCounter. Not sure if that requires elevation though. But I know who knows. +Bruce Dawson 

skyostil@
You can also get all kinds of swapping related events and counters from Linux perf, although I'm not sure if we have a good way of accessing it on end-user devices.

brucedawson@
I believe that getting information on hard faults on Windows requires elevation. It can probably be done with Pdh and/or Performance Monitor stuff, and it can definitely be done with ETW, but all of these require elevation.
Even Task Manager does not display hard faults - the page faults column is soft faults (unless they've changed things) which are not as interesting. That is presumably because task manager normally doesn't require elevation.