olka@chromium.org fhernqvist@google.com tguilbert@chromium.org webrtc-audio-uma@google.com xhwang@chromium.org media-dev-uma@chromium.org xhwang@chromium.org media-dev-uma@chromium.org ckitagawa@chromium.org fredmello@chromium.org jam@chromium.org joenotcharles@google.com chrome-memory@google.com The stack unwinder implementation used by the SamplingHeapProfiler. Emitted on Android devices only each time the profiler is started, which happens at Chrome launch when HeapProfiling.InProcess.Enabled is true. joenotcharles@google.com chrome-memory@google.com For every stack captured by the in-process heap profiler in {Process} on Android, records the percentage of stack frames whose address was not found in the Chrome module. Emitted at the time a snapshot is taken with an entry for every stack in the snapshot. joenotcharles@google.com chrome-memory@google.com For every stack captured by the in-process heap profiler in {Process} on Android, records if it has fewer than 5 frames. Stacks with few frames are low-quality and may indicate a problem with the stack unwinder. Emitted at the time a snapshot is taken with an entry for every stack in the snapshot. joenotcharles@google.com chrome-memory@google.com One metric is emitted on every process start, recording whether the in-process heap profiler is enabled in {Process} for this Chrome session. joenotcharles@google.com chrome-memory@google.com The number of samples in a heap snapshot taken in {Process}. Emitted once per snapshot when the in-process heap profiler is enabled. joenotcharles@google.com chrome-memory@google.com The time between heap snapshots taken in {Process} on {Platform}. Emitted for each snapshot when the in-process heap profiler is enabled, at the beginning and end of the snapshot interval. *.Scheduled histograms are recorded at the beginning of the interval, when the snapshot is scheduled. *.Taken histograms are recorded at the end of the interval, when the snapshot is taken. Entries in *.Scheduled that don't appear in *.Taken show which snapshot intervals are interrupted before the snapshot is taken. joenotcharles@google.com etienneb@chromium.org chrome-memory@google.com The total amount of memory in a heap snapshot taken in {Process}. This is an estimate of total memory allocations in the code being sampled. Because it is collected through random sampling it is only statistically accurate when aggregated over many reports. Emitted once per snapshot when the in-process heap profiler is enabled. joenotcharles@google.com chrome-memory@google.com The mean number of kilobytes between samples used by the SamplingHeapProfiler. Emitted each time the profiler is started, which happens at Chrome launch when HeapProfiling.InProcess.Enabled is true. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org TBD. erikchen@chromium.org ajuma@chromium.org chrome-analysis-team@google.com This metric is only recorded on iOS. This measures the sum of PrivateMemoryFootprint and SharedMemoryFootprint, which is possible because Chromium on iOS is single-process. Note that this does not include memory consumed by WebKit-launched processes, such as the WebContent and Network processes. Emitted when closing a log in order to upload it. This happens shortly after startup and again at regular intervals (usually 5 minutes, regardless of the type of network connection). Not emitted in logs that are closed when Chrome loses focus or closes. Yet, it is emitted on logs that are constructed from data persisted from a previous session, i.e., persisted from an unclean shutdown. Many changes in memory usage on iOS come from changes to WebKit, rather than changes within Chromium code. To assess whether a change in this metric is caused by a WebKit change, split by OS version. WebKit changes always come with an OS version change. As with other memory metrics, memory use tends to increase over time. Restarts due to OS or Chrome updates tend to make this metric drop. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. justincohen@chromium.org ajuma@chromium.org This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateActive. justincohen@chromium.org ajuma@chromium.org This metric is only recorded on iOS when UIApplication.sharedApplication.applicationState is UIApplicationStateActive. True if the sum of PrivateMemoryFootprint and SharedMemoryFootprint is greater than 200MB. According to Apple, apps on iPhone 6 and older devices get terminated by the OS if memory usage crosses 200MB watermark, so it's important to keep the memory usage under 200MB. "true" value may not show up on iPhone 6 and older devices if iOS is strict about the advertised watermark. justincohen@chromium.org ajuma@chromium.org This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateBackground. According to Apple, apps get terminated by the OS if memory usage in background crosses 50MB watermark, so it's important to keep the memory usage under 50MB. The timing of this metric will line up so that it rarely occurs when the app is in the background. With a small data set, the metrics might be biased in ways that we can't think of right now. justincohen@chromium.org ajuma@chromium.org This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateInactive. The timing of this metric will line up so that it rarely occurs when the app is inactive. With a small data set, the metrics might be biased in ways that we can't think of right now. ajuma@chromium.org rkgibson@google.com Investigation into crbug.com/1102494 shows that OverscrollActionsController is allocating thousands of objects in it's -initWithScrollView:. This is likely because thousands of OverscrollActionsControllers are being initialized. The theory is that there are users that have many many tabs, causing many OverscrollActionsControllers to be allocated. This histogram tests that theory by logging how many live OverscrollActionsControllers there are. This is recorded every time histograms are uploaded. ajuma@chromium.org rkgibson@google.com Investigation into crbug.com/1102494 shows that OverscrollActionsController is allocating thousands of objects in it's -initWithScrollView:. This is likely because thousands of OverscrollActionsControllers are being initialized. The theory is that there are users that have many many tabs, causing many OverscrollActionsControllers to be allocated. This histogram tests that theory by logging how many open tabs there are. This is recorded every time histograms are uploaded. justincohen@chromium.org ajuma@chromium.org This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but recorded right after the app transitions into background. According to Apple, apps get terminated by the OS if memory usage in background crosses 50MiB watermark so it's important to keep the memory usage under 50MiB. erikchen@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the browser process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. This histogram was used to measure the impact of the DestroyProfileOnBrowserClose prior to its general launch. Now that it's 100% launched, there is no active A/B test. nicolaso@chromium.org cbe-eng@google.com Same as Memory.Browser.PrivateMemoryFootprint, but only gets recorded after a Profile becomes safe to delete during this browsing session. This lets us measure the memory impact of destroying Profile objects and their KeyedServices. This is not meant to be compared with Memory.Browser.PrivateMemoryFootprint, as it measures a different scenario. Instead, it should be compared with itself in an A/B test with the DestroyProfileOnBrowserClose variation. erikchen@chromium.org ssid@chromium.org An amount of private memory of the browser process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. fdoray@chromium.org The size of the resident memory in the browser process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org A rough estimate of the shared memory footprint of the browser process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org TBD. No longer needed since the experiment was not launched. thiabaud@google.com lizeb@chromium.org Records how long it takes for memory to be released from the freelist of the discardable shared memory allocator with |madvise|. Note that clients without high-resolution clocks will report 0 for very short times. thiabaud@google.com lizeb@chromium.org Amount of resident memory that was in use but has now been moved to the freelist. Recorded during |OnMemoryDump|. thiabaud@google.com lizeb@chromium.org Freelist size used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. thiabaud@google.com lizeb@chromium.org Boolean metric which tracks whether or not large chunks of discardable memory are allocated from the freelist or via IPC. thiabaud@google.com lizeb@chromium.org Boolean metric which tracks whether or not discardable memory had already been discarded when an attempt is made to lock it. thiabaud@google.com lizeb@chromium.org Effective memory used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. thiabaud@google.com lizeb@chromium.org Virtual memory used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. reveman@chromium.org thiabaud@google.com The discardable memory allocation size in KB. Recorded each time a new discardable memory instance is created. anthonyvd@chromium.org catan-team@chromium.org The amount of available physical memory on the system as reported by base::SysInfo::AmountOfAvailablePhysicalMemory(). Recorded every 2 minutes. anthonyvd@chromium.org catan-team@chromium.org The percentage of physical memory on the system considered "available" by base::SysInfo::AmountOfAvailablePhysicalMemory() and base::SysInfo::AmountOfPhysicalMemory(). Recorded every 2 minutes. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org The physical footprint of the GPU process on macOS. Other measurements fail to correctly account for OpenGL memory usage. This metric also has flaws and is not intended for permanent use. It's an emergency measure added to help debug https://crbug.com/713854. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. anthonyvd@chromium.org catan-team@chromium.org The percentage of physical memory on the system considered "available" by base::SysInfo::AmountOfAvailablePhysicalMemory() and base::SysInfo::AmountOfPhysicalMemory(). The amount of "file-backed" memory is subtracted from the amount of available memory to attempt to estimate the available memory, counting the Page Cache as available. Recorded every 2 minutes on MacOS. anthonyvd@chromium.org catan-team@chromium.org The amount of memory reported as "file-backed" or associated to "external_pages" by vm_stat. Recorded every 2 minutes on MacOS. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in MiB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in KiB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. ssid@chromium.org bashi@chromium.org The renderer process' private memory footprint when a foreground OOM occurs. This was last recorded metric by renderer a few seconds before getting killed. yuzus@chromium.org keishi@chromium.org Records the time since last main frame navigation start on the renderer process when high memory usage is detected. Record only when navigation happened at least once. ssid@chromium.org haraken@chromium.org Records the time since last main frame navigation start on the renderer process when it OOMs in foreground visible state. Record 0 if no navigation was started. yuzus@chromium.org keishi@chromium.org Records the time since starting monitor on renderer when high memory usage is detected. tasak@google.com bartekn@google.com The highest private memory footprint of a renderer process in (X mins after the first page navigation, Y mins after the first page navigation]. (X, Y] is (0, 2], (2, 4], (4, 8], and (8, 16]. The metric is recorded at the Y's timing. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. keishi@chromium.org tasak@chromium.org The renderer process' private memory footprint 10 seconds after a memory pressure signal is generated. keishi@chromium.org tasak@chromium.org The renderer process' private memory footprint right before a memory pressure signal is generated. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. tasak@google.com chrome-memory-tok@google.com The total private memory footprint 10 seconds after a user-level memory pressure signal is generated. Recorded on Android. tasak@google.com chrome-memory-tok@google.com The total private memory footprint right before a user-level memory pressure signal is generated. Recorded on Android. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. tasak@google.com chrome-memory-tok@google.com The total private memory footprint excluding lower priority renderers' 10 seconds after a user-level memory pressure signal is generated. Recorded on Android. tasak@google.com chrome-memory-tok@google.com The total private memory footprint excluding lower priority renderers' right before a user-level memory pressure signal is generated. Recorded on Android. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the extension process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. fdoray@chromium.org The size of the resident memory in an extension process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the extension process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org The number of glyph pages present in the renderer when it commits a load. Since this is per-sub-process, you can get the average number of glyph pages in the system by multiplying this number with the average number of renderers. Note that this typically won't count the glyph pages added as a result of the load that just committed, since layout will happen after the commit. There are 512 bytes per glyph page, but this number also very closely approximates the number of glyph width map pages in the same renderer. The only difference is that if you have font fallback, it will make a new glyph page and no width page, but in most common cases there is no fallback). Width pages are 1K each (256 floats), so you could think of this value as being the number of "1.5K units related to glyphs per renderer per page load". jonross@chromium.org graphics-dev@chromium.org The maximum amount of memory of the GPU process allocated by {Source} during the following user interaction: {Usage}. See Memory.GPU.PeakMemoryUsage2. jonross@chromium.org graphics-dev@chromium.org The maximum amount of memory of the GPU process during the following user interaction: {Usage}. erikchen@chromium.org ssid@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the gpu process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. erikchen@chromium.org ssid@chromium.org An amount of private memory of the GPU process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. fdoray@chromium.org The size of the resident memory in the GPU process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the gpu process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. hajimehoshi@chromium.org erikchen@chromium.org kenjibaheux@google.com kouhei@chromium.org bgeffon@chromium.org System-wide graphics driver memory consumption. Recorded on Chrome OS for platforms where it is exposed by the kernel (for example, Intel i915 and Exynos Mali). Recorded once per UMA ping. khmel@google.com vovoy@google.com Cumulative count of low memory kills in one user session. This is recorded by MemoryKillsMonitor every time a low memory kill occurs. khmel@google.com vovoy@google.com When Chrome OS is in low memory state, TabManager kills some victims to free memory. This value is the elapsed time between TabManager receiving the low memory notification and the first kill. khmel@google.com vovoy@google.com The memory size freed by each low memory kill event. lizeb@chromium.org pasko@chromium.org The size of the resident memory for the native library code across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org Result of an attempt to read /proc/self/pagemap when determining the amount of resident memory mapped by the current process. Reading the file is performed as part of computing the Memory.NativeLibrary.MappedAndResidentMemoryFootprint2 histogram. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org The size of the native library code which was ordered, yet is not resident in memory, across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org The size of the native library code which is outside the ordered section, yet is resident in memory, across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the network service process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org An amount of private memory of the network service process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing for mid-2020 due to expiry. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org The size of the resident memory in a network service process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the network service process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing for mid-2020 due to expiry. oshima@chromium.org alemate@chromium.org System-wide memory allocation right after a renderer was killed by oom-killer, roughly equivalent to the sum of memory allocated with malloc() in userspace plus graphics driver memory. oshima@chromium.org alemate@chromium.org System-wide shared memory right after a renderer was killed by oom-killer. Used primarily for shared buffers in the graphics system. Tracked because it's a historical source of leaks on Chrome OS. oshima@chromium.org alemate@chromium.org System-wide memory allocation right after a renderer was killed by oom-killer, roughly equivalent to the sum of memory allocated with malloc() in userspace plus graphics driver memory. oshima@chromium.org alemate@chromium.org System-wide file-backed memory plus free memory right after a renderer was killed by oom-killer, which should be smaller than or close to what the kernel uses to trigger low-memory notifications for tab discards. If this is higher than the kernel's threshold for tab discards, renderers may be killed due to reasons other than out-of-memory. oshima@chromium.org alemate@chromium.org Graphics driver (GEM object) memory right after a renderer was killed by oom-killer. oshima@chromium.org alemate@chromium.org System-wide shared memory right after a renderer was killed by oom-killer. Used primarily for shared buffers in the graphics system. Tracked because it's a historical source of leaks on Chrome OS. vovoy@google.com wvk@google.com Cumulative count of OOM kills in one user session. vovoy@google.com src/chromeos/ash/components/memory/OWNERS The number of OOM kills since last emit. The emit interval is at least 24 hours, see metrics::DailyEvent for more details. dcastagna@chromium.org ssid@chromium.org The total number of open file descriptors opened per process. Recorded once per UMA ping. dcastagna@chromium.org ssid@chromium.org The limit of open file descriptors that can be opened per process. Recorded once per UMA ping. thiabaud@google.com lizeb@chromium.org Whether the disk allocator is usable. Recorded at the same time as "Memory.ParkableImage.*.5min". The disk may not be usable for several reasons, including the profile being an Incognito one, permssions error, or disk write error. thiabaud@google.com lizeb@chromium.org Size of encoded image data of ParkableImages that are on disk. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is read from disk. Records the time taken to read a ParkableImage from disk. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is read from disk. Records the throughput of reading the ParkableImage from disk, in MiB/s. thiabaud@google.com lizeb@chromium.org Total time spent reading images from disk. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Total size of encoded image data of ParkableImages. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Total time spent writing images to disk. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Size of encoded image data of ParkableImages that are not written to disk. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is written to disk. Records the time taken to write the ParkableImage to disk. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is written to disk. Records the size of the write, in KiB. lizeb@chromium.org Total size of compressed ParkableStrings, in KB. Recorded at the same time as "Memory.ParkableString.TotalSizeKb". lizeb@chromium.org thiabaud@google.com Time to compress a ParkableString, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. lizeb@chromium.org thiabaud@google.com Size of a compressed ParkableString, recorded at compression time. lizeb@chromium.org pasko@chromium.org Average compression ratio, 100 * compressed_size / initial_size, for all compressed ParkableStrings. Recorded at the same time as "Memory.ParkableString.TotalSizeKb.5min". lizeb@chromium.org thiabaud@google.com Time to decompress a ParkableString, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. lizeb@chromium.org thiabaud@google.com Original size of a compressed ParkableString, recorded at decompression time. lizeb@chromium.org pasko@chromium.org Total main thread time used by ParkableStrings for reading over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. lizeb@chromium.org pasko@chromium.org Total time used by ParkableStrings for writing to disk over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. lizeb@chromium.org pasko@chromium.org Total size of ParkableStrings discarded to disk, excluding allocator waste, in KB. Recorded once, 5 minutes after the first ParkableString is added to a renderer, at the same time as "Memory.ParkableString.MemorySavings.5min". lizeb@chromium.org pasko@chromium.org Time to read a ParkableString from disk, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. lizeb@chromium.org pasko@chromium.org Sum of memory saved by compression, in KB. Recorded at the same time as "Memory.ParkableString.TotalSizeKb". lizeb@chromium.org pasko@chromium.org Total size of ParkableStrings assuming no compression, in KB. Recorded once, 5 minutes after the first ParkableString is added to a renderer, at the same time as "Memory.ParkableString.MainThreadTime.5min". lizeb@chromium.org bartekn@chromium.org Time it takes for PartitionAlloc's MemoryReclaimer to reclaim once. Collected at each reclaim, for all process types. Note that clients without high-resolution clocks will report 0 for very short times. bartekn@chromium.org keishi@chromium.org Size of the extras configured for PartitionAlloc's `PartitionRoot` struct. This is specific to the main partition, which powers the bulk of PartitionAlloc-Everywhere. Recorded once for each process during allocator shim configuration. Extras are optional. Extras can include the PartitionAlloc cookie (16B) and the MiraclePtr ref-count (up to 16B). lizeb@chromium.org bartekn@chromium.org Time it takes for PartitionAlloc's periodic purge to run once. Collected at each purge, for all process types. Note that clients without high-resolution clocks will report 0 for very short times. lizeb@chromium.org bartekn@chromium.org Fraction of PartitionAlloc's thread cache allocations requests that required a batch fill, that is cache hits touching the central allocator. Recorded during memory dumps, at the same time as the Memory.*.PartitionAlloc.* histograms. Data is collected for {ThreadType}. lizeb@chromium.org bartekn@chromium.org Hit rate for PartitionAlloc's thread cache. Recorded during memory dumps, at the same time as the Memory.*.PartitionAlloc.* histograms. Data is collected for {ThreadType}. fdoray@chromium.org catan-team@chromium.org The time spent in each memory pressure state, in seconds. Recorded when the memory pressure state changes, at shutdown, or when it hasn't been recorded in the last 5 minutes. The values from this histogram shouldn't be used directly, users of this metric should look at the percentage of samples in each bucket to understand the average time that Chrome spend in each pressure state. chrisha@chromium.org The number of pressure level state changes for each possible pairwise state change. fdoray@chromium.org catan-team@chromium.org The time spent in each of the memory pressure state. Recorded when transitioning from a memory pressure state to the other and when exiting memory pressure. creis@chromium.org nasko@chromium.org The count of all active processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. pasko@chromium.org leszeks@chromium.org The state of CachedMetadata on every attempt to use it for a script resource. Used for experiment in http://crbug.com/1045052. hajimehoshi@chromium.org The esitimated memory size which would be reduced when reusing disk cache is implemented. If it is 100% sure that the encoded data is in disk cache, the same data in memory can be dropped to reduce memory usage. This is rencorded when an ImageResource is pruned. See crbug/664437. erikchen@chromium.org ssid@chromium.org speed-metrics-dev@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the renderer process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. Do not modify this metric in any way without contacting speed-metrics-dev@chromium.org AND chrome-analysis-team@google.com. fdoray@chromium.org The size of the resident memory in a renderer process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the renderer process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. creis@chromium.org nasko@chromium.org The count of active renderer processes. Excludes renderers hosting chrome-extension:// and/or chrome:// URLs. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on OS data. WARNINGS: Not reliable on Android, see https://crbug.com/875400. Ignores processes that do not host a widget, see https://crbug.com/949977#c36. Consider using Memory.RenderProcessHost.Count.* instead. alexmos@chromium.org creis@chromium.org lukasza@chromium.org nasko@chromium.org The count of all renderer processes. Covers all renderer processes, including ones hosting web content (i.e. http(s):// and/or file://), extensions (i.e. chrome-extension://) and WebUI (i.e. chrome://). Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on count of RenderProcessHost objects, even if 1) they have not been launched yet (e.g. during session restore) or 2) they are dead (e.g. killed by the browser process or the OS). alexmos@chromium.org creis@chromium.org lukasza@chromium.org nasko@chromium.org The count of active renderer processes. Recorded once per UMA ping. Covers all renderer processes, including ones hosting web content (i.e. http(s):// and/or file://), extensions (i.e. chrome-extension://) and WebUI (i.e. chrome://). Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on count of RenderProcessHost objects that are IsInitializedAndNotDead (i.e. have been launched and not terminated yet). wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org An estimate of additional processes created due to OriginAgentCluster (OAC). Computed assuming no coalescing of multiple BrowsingInstances into a single RenderProcess (including no subframe process reuse), and only when cross-process origin isolation occurs due to the OAC header. Given this, the count of additional SiteInstances corresponds exactly to the additional number of RenderProcesses that OAC gives rise to, and therefore gives a sense of how much process count overhead it creates. Recorded once per UMA ping. wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org The number of renderer processes that represent sandboxed iframes, computed by counting the number of RenderProcessHosts allocated to them. This will be zero when SiteIsolationPolicy::AreIsolatedSandboxedIframesEnabled() is false. Recorded once per UMA ping. wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org The percentage of the total renderer process count that is due to the OriginAgentCluster (OAC) header, based on the overhead estimate from Memory.RenderProcessHost.Count.OriginAgentClusterProcesses. That value is computed assuming no coalescing of multiple BrowsingInstances into a single RenderProcess (including no subframe process reuse), and only when cross-process origin isolation occurs due to the OAC header. Given this, the percentage of total SiteInstances due to the OAC header corresponds exactly to the percentage of RenderProcesses that OAC gives rise to. Recorded once per UMA ping. reveman@chromium.org The amount of free space in temporary directory for shared memory files. Recorded each time a new discardable memory manager instance is created. Replaced by Memory.StackSamplingProfiler.StackSampleSize2. Min bucket size was too large to be useful. Replaced April 2023. iby@chromium.org cros-telemetry@google.com The size of the stack copied during a stack-sampled metric capture. One sample per 199 stack captures. Only recorded by clients in the stack-sampled metrics experiment. ChromeOS only. iby@chromium.org cros-telemetry@google.com The size of the stack copied during a stack profiler capture. One sample per 199 stack captures. Only recorded by clients in the stack-sampled metrics experiment or recording a Chrometto trace. ChromeOS only. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org The swap used by each worker process. Each worker process provides one sample. Recorded once per process per UMA ping if the system has swapped. fdoray@chromium.org catan-team@chromium.org The amount of available physical memory on the system. Recorded every 5 seconds on Windows only. From https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-memorystatusex, this is memory that can be reused without having to write its content to disk first. It includes the standby, free and zero lists. andreaorru@chromium.org hidehiko@chromium.org System-wide estimate of memory available in ChromeOS, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone. The estimate takes into account that the system needs some page cache to function well, and that not all reclaimable slab will be reclaimable, due to items being in use. andreaorru@chromium.org hidehiko@chromium.org System-wide estimate of memory used in ChromeOS, calculated as the difference between the amount of total and available memory. lizeb@chromium.org chrome-memory@chromium.org Total size of all hibernated canvases across all renderers, prior to compression. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. lizeb@chromium.org chrome-memory@chromium.org Total size of all hibernated canvases across all renderers. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. erikchen@chromium.org ssid@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of all processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. This histogram was used to measure the impact of the DestroyProfileOnBrowserClose prior to its general launch. Now that it's 100% launched, there is no active A/B test. nicolaso@chromium.org cbe-eng@google.com Same as Memory.Total.PrivateMemoryFootprint, but only gets recorded after a Profile becomes safe to delete during this browsing session. This lets us measure the memory impact of destroying Profile objects and their KeyedServices. This is not meant to be compared with Memory.Total.PrivateMemoryFootprint, as it measures a different scenario. Instead, it should be compared with itself in an A/B test with the DestroyProfileOnBrowserClose variation. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all processes on Android ignoring Renderers with only Waived process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all visible or higher importance processes on Android. This ignores Renderers with Waived or Not Perceptible effective process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. fdoray@chromium.org lizeb@chromium.org Memory from the Blink heap in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. fdoray@chromium.org lizeb@chromium.org Memory from the Blink heap which is not used by allocated objects in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. keishi@chromium.org bartekn@chromium.org A rough estimate of memory allocated by malloc in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. tommckee@chromium.org A rough estimate of the private memory footprint of all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all renderer processes on Android ignoring Renderers with only Waived process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all renderer processes with visible or higher importance on Android. This ignores Renderers with Waived or Not Perceptible effective process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. fdoray@chromium.org The size of the resident memory in all processes. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: This metric is a simple sum of the resident set of all processes and this cause some double accounting for the shared portion of the working set. As a result this metric doesn't give an exact representation of how much physical memory is used by Chrome. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of all processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. zmo@chromium.org graphics-dev@chromium.org Records the system commit limit (number of total pages) x page size, collected in the info collection GPU process, once per UMA ping. This is Windows platform only. lizeb@chromium.org chrome-gpu-memory@google.com Total (GPU) memory used for tiles, across all consumers. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. kawasin@google.com sstan@google.com The total bytes written by vmm-swap feature for a week. This is sent weekly once any disk writes for vmm-swap has done. Once reporting has started it reports weekly even if the total bytes written is zero. kawasin@google.com sstan@google.com The duration how long it was spent with vmm-swap enabled. This is sent with ".InactiveBeforeEnableDuration" metrics when vmm-swap is disabled. Shorter ".InactiveBeforeEnableDuration" and longer ".ActiveAfterEnableDuration" indicates the vmm-swap policies are doing a good job at deciding when to enable vmm-swap. kawasin@google.com sstan@google.com An lower bound estimate of the average number of pages resident on disk over the duration of the vmm-swap period. Even if the actual page size is not 4KiB, it is recalculated to be the number of 4KiB pages. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com Tracks events that would cause vmm-swap to be disabled. This is sent regardless of whether or not vmm-swap was actually active - i.e. alongside both ".ActiveAfterEnableDuration" and ".InactiveNoEnableDuration". Each event type is broken down into two enum values - one for the inactive and one for the active case. kawasin@google.com sstan@google.com The duration how long it was spent waiting to enable vmm-swap since it becomes swappable-idle. This is sent with ".ActiveAfterEnableDuration" metrics when vmm-swap is disabled. kawasin@google.com sstan@google.com The duration how long it was spend without vmm-swap enabled and it exits swappable-idle. This is sent when vmm-swap is disabled. If reported values are mostly long, it indicates that the policies are missing chances to enable vmm-swap. kawasin@google.com sstan@google.com The minimum number of pages resident on disk any given point during the vmm-swap period. Even if the actual page size is not 4KiB, it is recalculated to be the number of 4KiB pages. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com The average duration of each page of the guest memory lives in the swap file. We expect most cold pages live in the swap file for a long time and hot pages are not swapped out but kept in the memory. The durations are measured every 10 minutes to estimate the average duration. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com Tracks the policy decision made when deciding how to handle a swap enable dbus request. Indicates if a request was accepted or why it was rejected. Each decision result is further broken down into whether it occured while handling an initial enable request or a maintenance request. kawasin@google.com sstan@google.com Sends the vmm-swap state (enabled or disabled) every 10 minutes while the vm is swappable-idle. Vmm-swap may not be enabled by policies to protect disk. This metrics indicates what percentage of time in the swappable-idle state is spent with vmm-swap enabled and how well the policies works. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org The private working set used by each worker process. Each worker process provides one sample. Recorded once per process per UMA ping. bgeffon@chromium.org fdoray@chromium.org Cumulative number of ARC processes trimmed during a user's session, recorded each time an ARC process is trimmed. Available on ChromeOS. khmel@chromium.org bgeffon@chromium.org Number of ARCVM's crosvm trimmed in the last 30 minutes. Recorded every 30 minutes as long as ARCVM trimming is enabled. Available on ChromeOS. Also, one last report is emitted for the <= 30 minute period since the last report, at browser exit, and that the sample is scaled. For example, when 1 trim was done since the last report and the browser exits 15 minutes after the last report, 2 is recorded on the browser exit. raging@google.com khmel@chromium.org bgeffon@chromium.org Tracks the number of failures that resulted from ArcVM trim operations. Recorded every 30 minutes as long as ARCVM trimming is enabled. Available on ChromeOS. Also, one last report is emitted for the <= 30 minute period since the last report, at browser exit. raging@google.com khmel@chromium.org bgeffon@chromium.org Tracks the ongoing computed value used to limit the number of pages to trim each time the ArcVM operation runs. Available on ChromeOS. If VM trimming is enabled, this is recorded at the start of every trim operation, with the page limit computed for each operation. Values tracked as zero mean unlimited trimming. bgeffon@chromium.org fdoray@chromium.org Cumulative number of renderers trimmed during a user's session, recorded each time a renderer is trimmed. Available on Windows and ChromeOS. erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the {UtilityProcessType} process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org An amount of private memory of the {UtilityProcessType} process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing for mid-2020 due to expiry. fdoray@chromium.org The size of the resident memory in a {UtilityProcessType} process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the {UtilityProcessType} process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing between M77 to M87 due to expiry. jonross@chromium.org chrome-gpu-metrics@google.com The total count of viz::SurfaceIds being evicted for the current FrameTree. Along with any surfaces that were embedded before a navigation occurred. This will be emitted whenever we evict one DelegatedFrameHostAndroid. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org Reasons behind evictions of individual tabs, recorded upon each tab eviction. hajimehoshi@chromium.org kenjibaheux@google.com kouhei@chromium.org Number of loaded (memory-resident) tabs when LowMemory notification is delivered. ssid@chromium.org chrome-metrics-team@google.com Whether Chrome is running in low ram mode. This histogram is reported on every upload by Android devices. A device is considered low-RAM if it has 512MiB of RAM or lower (see SysUtils.detectLowEndDevice()).