Chrome on Windows displays private resident pages (private working set). At the time this was made to work this way this was consistent with other platforms, but they may have changed. Memory metrics are always a tradeoff. Private-committed memory will overestimate our footprint, whereas private-resident pages will (when under memory pressure) underestimate our footprint. Private-resident plus paged-out memory would be ideal but does not seem to be possible on Windows.

The memory column should *not* display shared pages. That would be my main request.

If we change task manager to show a percentage of a core then we should tweak the title to make this obvious. If we do that then I have no concerns. The extra precision and the more intuitive meaning and the consistency (across OSes and across different core counts) is highly desirable.

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

commit 4ae8f2924c42601192fff8e6b887c3c76a6d0483
Author: Wez <wez@chromium.org>
Date: Mon Sep 11 20:52:03 2017

Remove platform-dependent ProcessMetrics::GetCPUUsage() API.

GetCPUUsage() returned different measures of CPU usage on Windows to
that used on other platforms. This required us to also have a
GetPlatformIndependentCPUUsage() API for call-sites that cared about
consistent metrics across platforms, such that only TaskManager used
the inconsistent API.

This CL makes the following changes:
- Update the TaskManager to use GetPlatformIndependentCPUUsage().
- Rename TaskManager::GetCPUUsage to GetPlatformIndependentCPUUsage.
  (Plus similar renaming for TaskGroups's CPU usage members.)
- Change the chrome.processes' API implementation of Process.cpu to
  report percentage-of-one-core usage rather than percentage-of-total.
  This was already the behaviour on non-Windows platforms, and was
  apparently the expectation of callers, in spite of the existing
  documentation stating otherwise.
- Update the documentation on the Process.cpu to make the meaning of
  the returned value more explicit.

Bug:  741202 
Change-Id: I313b56399df4f26cf995131793799e532e481942
Reviewed-on: https://chromium-review.googlesource.com/598750
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Reviewed-by: Charlie Reis (slow) <creis@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501033}
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics.h
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_freebsd.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_fuchsia.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_ios.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_linux.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_mac.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_openbsd.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_unittest.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/base/process/process_metrics_win.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/chromeos/resource_reporter/resource_reporter.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/chromeos/resource_reporter/resource_reporter_unittest.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/extensions/api/processes/processes_api.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/sampling/task_group.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/sampling/task_group.h
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/sampling/task_group_sampler.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/sampling/task_manager_impl.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/sampling/task_manager_impl.h
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/task_manager_interface.h
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/test_task_manager.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/task_manager/test_task_manager.h
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/browser/ui/task_manager/task_manager_table_model.cc
[modify] https://crrev.com/4ae8f2924c42601192fff8e6b887c3c76a6d0483/chrome/common/extensions/api/processes.idl

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

commit 0a41b75286caf83656ae4c065fc9b9246247a6f7
Author: Wez <wez@chromium.org>
Date: Fri Sep 15 02:06:34 2017

Restore ProcessMetrics::GetPlatformIndependentCPUUsage to percentage.

While iterating on the CL to remove GetCPUUsage() and replace callers
with the platform-independent version, it was broken to return CPU usage
as a multiple-of-one-core, rather than percent-of-one-core.

This restores the value to the percent-based range.

Bug:  741202 
Change-Id: I4866f2748dbdab800421561d8fc849d88c73280f
Reviewed-on: https://chromium-review.googlesource.com/668098
Commit-Queue: Wez <wez@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502130}
[modify] https://crrev.com/0a41b75286caf83656ae4c065fc9b9246247a6f7/base/process/process_metrics_win.cc

 Issue 117866  has been merged into this issue.

I'm not seeing any sign of this change in canary. I just ran Sun Spider on my canary build (which I have confirmed was built today) and CPU usage peaked at about 1.6%. I would have expected something in the 40-100% range. This is on a 48-way machine where ~2% used to represent a fully loaded core, and it seems to still do that.

Re #8: Sadly when the CL in #4 landed it change things to report number-of-cores used per-process, rather than percentage-of-core used, i.e. for a single-threaded process the range is 0..1.0 rather than 0..100.

On your lovely 48-core beast of a machine you'd be forgiven for thinking nothing changed since this would appear as a ~2x reduction in reported CPU usage relative to the percentage-of-total number. :P

Tonight's Canary should have the correct range; apologies for the confusion.