For a simpler case, I tried running Chromium on an empty profile.

1) Set up Chromium to take a memory-infra trace.
2) In a terminal as root, run ```sleep 5; sudo vmmap -v -interleaved <pid>``` 
3) Press the start button to take the memory-infra trace.

This ensures that the memory-infra trace as closely as possible matches the vmmap. The gpu MemoryDumpProvider claims 23,486K effective size [all in textures], 65,933K size. [Stays the same across multiple detailed dumps]. Number of texture: ~80.

vmmap claims 37.6MB virtual IOKit memory, 27M resident/dirty/non-vol across 159 regions.

Deleted: trace_gpu_vmmap_example.json.gz 1.9 MB

trace_gpu_vmmap_example.json.gz 1.9 MB Download

Deleted: gpu_vmmap_example 266 KB

gpu_vmmap_example 266 KB View Download

Sorry, missed this earlier, will take a look tonight

Please see the two sections on OpenGL:
https://docs.google.com/document/d/1vltgFPqylHqpxkyyCM9taVPWNOTJkzu_GjuqdEwYofM/edit#heading=h.58o6s9wjn3lk

IOKit memory includes memory used for OpenGL [non-IOSurfaces]. I think it would be *nice* to track this memory, but don't have a precise way of doing this. At the very least, note that the first CGLContext takes 1700KB, and subsequent ones take 500KB. 

So, a few things:

- We still have a double-counting issue in GPU - tracked in crbug.com/571026 - waiting on a memory-infra fix for this. If the fix in memory-infra is too far out, I can tweak things so we still double count between CC/GPU, but at least the single number from GPU can be looked at in isolation and will provide the right number. We will then still need changes to memory infra to eliminate the CC/GPU double counting.

- Additionally, it's possible that IOKit is holding memory that Chrome has freed, for potential re-use. If this is the case, you should be able to issue a critical memory pressure signal "sudo memory_presssure -S -l critical", and this memory will move into the "EMPTY SIZE" category in vmmaps.

On my machine, running the test from #1, running memory pressure first does bring numbers more into line with what's expected. However' we're still off by ~15%.

Might be due to the issues you mention in #3, or some other GL support stuff. May also be due to browser UI IOSurfaces, which I think we draw using mac native APIs? Or are those tracked on the browser?

I was talking with ericrk: 

1) gpu MDP overcounts. We want gl: (size - effective_size).

2) transfer_memory is cpu memory used by command buffers to transfer data between renderer and GPU, implemented as base::SharedMemory and doesn't count towards IOKit. 

Using (1), both on the example in c#1, and locally, shows that gpu MDP reports [within a couple of MB] the same results of vmmap's IOKit section. Those couple of MBs can easily be explained as footprint of CGLContexts.

On a real instance of Chrome Canary, I observe:
Nonvol IOKit: 506.1M
chrome tracing: 348MB gl effective_size, 850MB size, for ~502MB. Once again, the difference is only a couple of MB.

Other than GPU over-counting, which ericrk said he would address, I think everything else is working correctly.