Issue metadata
Sign in to add a comment
|
memory-infra accounting for cc has confusing nomenclature/organization |
||||||||||||||||||||||||
Issue descriptionThis bug has the relevant memory traces: https://bugs.chromium.org/p/chromium/issues/detail?id=693968#c3 It looks like cc is using 400+MB for a single renderer, based on cc:effective_size. But drilling down, we see that most images have "0" effective size, and summing all images does not add to ~400MB. It looks like we only emit "locked size" when the image is locked, but somehow this name is lost and becomes "effective size". https://cs.chromium.org/chromium/src/cc/tiles/software_image_decode_cache.cc?type=cs&q=%22cc/image_memory/cache_0x%25%22&l=863 So several requests: 1) Can we emit both "total memory" and "total locked memory" for the cc MemoryDumpProvider? 2) Can we emit both for the breakdown as well [per image]?
,
Feb 21 2017
From the second trace on the referenced but, I do see the images properly adding up to ~400mb. I'm going to write a patch to always report locked size whether or not the image is locked. Is it possible that 0 size 0 effective size images are discarded (as opposed to other images that are still capable of being locked?) I'm not too familiar with discardable memory code that dumps memory.
,
Feb 22 2017
I can see how this is a bit confusing. We actually do log pretty much what you want, but we would only log "locked_size" if the object is locked. In the trace you saw, nothing was locked, meaning that we never had any "locked_size" entries and the column was never generated - vmpstr@ is putting together a CL to always log locked size, even if 0, which should make this easier to read. In terms of how the effective_size / size gets logged - it's actually handled by some logging code in the discardable memory object - see https://cs.chromium.org/chromium/src/cc/tiles/software_image_decode_cache.cc?rcl=6d2d654291ab0740e2bb3d28c4025dc1405767fb&l=868 - this line calls DiscardableMemory::CreateMemoryAllocatorDump, which eventually tunnels through to https://cs.chromium.org/chromium/src/components/discardable_memory/common/discardable_shared_memory_heap.cc?rcl=6d2d654291ab0740e2bb3d28c4025dc1405767fb&l=465 where we log the size. Effective size is automatically equal to size unless the dump has more advanced sharing set up. So, after vmpstr@'s change, you'll get size/effective_size, as well as locked_size for all images as well as the CC category.
,
Feb 22 2017
Linked the wrong thing for the second link above, the size/effective-size are logged here: https://cs.chromium.org/chromium/src/components/discardable_memory/common/discardable_shared_memory_heap.cc?rcl=6d2d654291ab0740e2bb3d28c4025dc1405767fb&l=79 The incorrect link above (https://cs.chromium.org/chromium/src/components/discardable_memory/common/discardable_shared_memory_heap.cc?rcl=6d2d654291ab0740e2bb3d28c4025dc1405767fb&l=465) is actually the answer to vmpstr@'s question in #2, we log 0 for size/effective_size if the memory has been discarded.
,
Feb 22 2017
,
Feb 23 2017
This has landed in https://chromium.googlesource.com/chromium/src.git/+/7d1142a765ae5648b212d357e4db425e2fad3623 (sorry I referened the other bug in the CL) |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by erikc...@chromium.org
, Feb 21 2017