On MacOS, GMBs are always IOSurfaces.

Effective Size is an attempt to represent the size of an object without double-counting. This is important if an objects memory is reported multiple places. size does not take these precautions (so summing size across all categories results in over-estimating memory usage).

To give a concrete example, take GPU Memory Buffers which are used for CC tile memory. This buffers are:
 - Allocated by CC, and reported by CC/resource_memory and CC/tile_memory
 - Bound to a GL texture, and reported in GPU/gl/textures
 - Tracked by the GMB system and reported in gpumemorybuffer category

As these GMBs are reported 5 places (at least), it doesn't make sense to report their full size in each place, as it makes summing up top-level categories difficult. However, it's valuable to report the memory in each place to better understand where leaks come from.

Because of this, only one component (which dumps with highest importance) gets the GMB memory attributed to its "effective_size", the others get 0. In the above case, CC/tile_memory is the component that's actually keeping the buffer alive (and will eventually delete it), so it gets the "effective_size".

Effective_size is the value which gets propagated up to the top-level values.

Let me know if this makes sense and if you have any suggestions on improving things. Thanks!

I see, thanks for the explanation. This makes sense, and some documentation/UI would have been helpful, but the marginal cost of doing that is likely higher than just telling everyone who asks.

Maybe copy/paste somehow this conversation in
https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/probe-gpu.md

With every lgtm in docs/ my next lgtm comes with a 50% discount ;)