In terms of a UMA size: we are counting the outer size.
- Here is the line: https://cs.chromium.org/chromium/src/base/trace_event/memory_dump_manager.cc?l=764
- Here is the discussion about why we're using outer size: https://codereview.chromium.org/2760253005#msg9

In terms of slow reports: we do indeed seem to look at allocated_objects.
- If you open go/slow-memory-reports scroll down and click a trace link you can see the reported value in the dashboard matches the sum of 'malloc/allocated_objects' field in the trace.

We could go further and check to see if the ratio makes sense somehow (or see if we can compute total malloc size from the trace?) do you think it is worth it primiano@?

That does not make sense to me. On Android, where we get maximum number of slow report traces from the numbers for malloc and malloc/allocated_objects should be equal. So, there should be no difference because of choosing different metrics.
AFAIK slow reports use malloc and not allocated_objects_size.

The link for UMA has a filter for RAM size to 2-3GB. Slow reports does not have such filter for the average graph. Anyway after removing that filter the malloc average in UMA shows 37 and slow reports show 34.

Now the other issue is devices running on Canary and Dev could have 64 bit chrome and UMA does not seem to have a filter for that. Slow reports graph shows either 32bit or 64 bit only.
32bit avg: 34
64bit avg: 54

I am not sure if we can make a fair comparison now :(

You can filter by 32/64 bit in UMA: click the 'AND' button at the bottom of the filters then select 'bitness' in the first of the new dropdowns that appear. When I do this (and also remove the 2-3GB filter - nice catch) the numbers seem sensible (UMA < slow reports).

Ok I figured out.
1) I made a bunch of distraction mistakes:
 - the 2-3 GB filter is because of an early attempt of matching the histogram of SMM. I forgot to remove.
 - You are right about bitness.

I re-copy/pasted the data and now make sense.
I also figured out that the math for 95th percentile is different between UMA and SMM. This is because data in the UMA dynamic table is pre-bucketed so they take the 95th percentile of something that has been already bucketed. This explains why now the avg match but the 95th percentile diverge a bit.
No other action to be done here. We'll fix the rest once we move the graph pipeline into chrome.

Thanks for the inputs