Come up with a consistent set of memory metrics for Chrome Mac. |
|
Issue descriptionI'm working on a CL to expose more detailed memory metrics on mac: https://codereview.chromium.org/2601193002/. I decided to sanity check the numbers that were coming out - and to my surprise, they weren't matching other sources. List of sources: 1) Activity Monitor's memory panel has two columns: "memory" and "real memory". 2) vmmap outputs a large list of numbers, as well as an extremely detailed list of memory regions. Digging shows that there are two private frameworks: Symbolication/CoreSymbolication with a copious amount of code devoted to finding more information about memory regions. 3) ProcessMetrics::GetWorkingSetSize uses task_basic_info_64.resident_size. osfmk/kern/bsd_kern.c shows that this returns pmap_resident_count(map->pmap). 4) My newly written code in ProcessMetricsMemoryDumpProvider::DumpProcessMemoryMaps uses mach_vm_region_recurse. 5) ProcessMetrics::GetMemoryBytes uses mach_vm_region, and skips some regions using IsAddressInSharedRegion.
,
Feb 1 2017
mark: To clarify, I would expect task_vm_info.resident_size to be the sum of the resident size of all the vm regions [let's say from vmmap -v], but that's not it. It's also not just the dirty page, or just the vm regions not including frameworks. Since compressed memory seems to directly reduce from it, it's not clear how it could be computed from just VM regions if we don't also know the compression status.
,
Feb 1 2017
I don’t know off the top of my head. I tend to have to re-consult xnu source each time I want to figure out exactly how the different VM stats relate. As you found, libtop is a useful resource here.
,
Feb 3 2017
More detailed writeup: https://docs.google.com/document/d/1nWS37WCZHr1ry4w4wAfFIwO8qJW-KZ5641hdBOc6JEk/edit# |
|
►
Sign in to add a comment |
|
Comment 1 by erikc...@chromium.org
, Feb 1 2017I tried disassembling/real-time debugging of Activity Monitor to figure out where the numbers are coming from. [Break on "-[SMProcess setPrivateMemory:]", use raw addresses since lldb doesn't recognize these functions as ObjC]. They get updated [via KVO], by code in libsysmon.dylib, over xpc [presumably with sysmond]. sysmond is just a giant pile of xpc-handling code that uses some syscalls [nothing we don't know about]. There's a single method that calls mach_vm_region, and none that call mach_vm_region_recurse. That method is really large, but has the helpful assertion: """ __assert_rtn("libtop_update_vm_regions", "/BuildRoot/Library/Caches/com.apple.xbs/Sources/sysmond/sysmond-85/src/process-libtop-memory.c", 0x184, "0"); """ Copy-paste? top-108/libtop.c helpfully has a method libtop_update_vm_regions. I'll try that out to see if we should just duplicate the logic. Aside: The columns "Real Mem" and "Compressed Mem" come straight from task_vm_info.resident_size and task_vm_info.compressed. From observation, "Private Memory" is sometimes equivalent to the malloc regions. [Trying vmmap on Finder or compiler_proxy [goma]]. But then trying vmmap on WindowServer, which has almost no Private Memory [mostly shared] shows a very different story. I'm guessing that there's some custom accounting using mach_vm_region [which does exist in libtop]. mark: What is the relationship between task_vm_info.resident_size and the regions emitted from mach_vm_region? [Ideally we could derive the former from the latter]. mach_vm_region doesn't return details about compression, so are we perhaps seeing an entirely orthogonal view into the vm subsystem?