One idea would be to change the api of DumpMemoryStats to:
uint64_t DumpMemoryStats(ProcessMemoryDump* pmd, std::string& parent_absolute_name) const;
that does not add any dumps to |pmd| if Background mode and just returns a total number. But, we should find a way to not double count.

Maybe this calculation is something that must be done after collecting dumps, where net providers dump all the data and memory-infra aggregates the values and adds only total to the trace.

(1)
The current net MDP doesn't calculate the actual size of certs -- it only provides a lower bound. The double counting only occurs if the cert is shared between connections (The refcountedness of X509 is deep in BoringSSL stack). I don't think we can calculate the actual size or avoid the double counting there. X509 certs are moving to Cryto Buffer String ( Issue 671420 ), so that won't be an issue soon. I wouldn't spend too much time in figuring the *exact* allocation by certs, since it's technically complicated and the cert story is gonna change very soon.
(2)
If the number of allocator dumps is an issue, we can definitely reduce the number and report the total wherever applicable. By "double count," do you mean that AddOwnershipEdge() doesn't solve the problem and we need something else?

I saw a lot of code which does:
if (!dump_exists) {
  create dump;
  add size;
}

So, I just mentioned we should be careful not to double count when dumping the total usage to reduce the number of allocator dumps. Currently we do not use AddOwnershipEdge() for BACKGROUND mode since other columns dump the total usage with 1 or 2 allocator dumps and did not need ownership edges to get the total.

Re: #3 I think there are already CLs landed for issue  Issue 671420  and I see that ssl_session_cache is already instrumented with DumpMemoryStats. This sounds great.

I only have a few concerns before we enable on field trials.

I see a lot of http_network_session dumps of 0 size. Can we avoid dumping them?

Also, I was thinking we can skip the "url_request_context/XX" dumps ONLY on background mode. We will only have "http_network_session" dumps.
"url_request" dumps actually seems to double the number of allocator dumps added by net dump provider. If we figure out that we need this data for debugging in Slow Reports and we do not have too many http_session dumps, we can add them later.

wdyt?

> Also, I was thinking we can skip the "url_request_context/XX" dumps ONLY on background mode. We will only have "http_network_session" dumps.

How will we be able to denote the fact that an http_network_session is shared btw url_request_context/A and url_request_context/B ?

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

commit 8397c08b01935f854e527ba42c9563ba852f1981
Author: xunjieli <xunjieli@chromium.org>
Date: Fri Jan 20 23:13:59 2017

Skip creating spdy_session_pool dump if pool is empty in MemoryDumpProvider

This CL skips creating a MemoryAllocatorDump for spdy_session_pool if the
pool is empty.

R=ssid@chromium.org

BUG=677346, 669108 

Review-Url: https://codereview.chromium.org/2639403005
Cr-Commit-Position: refs/heads/master@{#445203}

[modify] https://crrev.com/8397c08b01935f854e527ba42c9563ba852f1981/net/spdy/spdy_session_pool.cc