Record swap metrics

content/browser/memory/swap_metrics_observer_win.cc

Index: content/browser/memory/swap_metrics_observer_win.cc
diff --git a/content/browser/memory/swap_metrics_observer_win.cc b/content/browser/memory/swap_metrics_observer_win.cc
new file mode 100644
index 0000000000000000000000000000000000000000..f80a5b5fa523bdba2ba05d829cf918534a5043e0
--- /dev/null
+++ b/content/browser/memory/swap_metrics_observer_win.cc
@@ -0,0 +1,16 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "content/browser/memory/swap_metrics_observer.h"
+
+namespace content {
+
+// static
+SwapMetricsObserver* SwapMetricsObserver::GetInstance() {
+  // SwapMetricsObserver isn't available on Windows for now.
+  // TODO(bashi): Figure out a way to measure swap rates on Windows.

[chrisha, 2017/05/03 15:55:56]

You can find detailed stats for a particular process (CoW faults, soft faults,
hard faults, file cache faults, etc) via undocumented NT internals:
NtQuerySystemInformation and SYSTEM_PERFORMANCE_INFORMATION. We have similar
code using this kind of functionality here:

https://cs.chromium.org/chromium/src/components/startup_metric_utils/browser/...

You can get system wide performance counters in various ways. There are many
"undocumented" structures that contain performance data, including:

VM_COUNTERS, SYSTEM_FILECACHE_INFORMATION, SYSTEM_MEMORY_USAGE,
SYSTEM_PAGEFILE_INFORMATION, SYSTEM_PERFORMANCE_INFORMATION_2 (extremely
detailed), SYSTEM_BASIC_PERFORMANCE_INFORMATION, SYSTEM_BASIC_INFORMATION_EX

There's also a whole "performance counter" API. This wraps many of the NT
internals, and is much slower but much more clearly documented. See
PdhOpenQuery, PdhAddCounter, PdhGetCounterInfo, PdhGetFormattedCounterInfo,
PdhCloseQuery.

Some experimentation needs to be done to figure out which NT internals are the
exact counters you want, when comparing them to the clearly documented
performance counters. However, in production code I'd use the NT internal APIs
directly as they are many many orders of magnitude faster than the performance
counters. (On my machine I could saturate a CPU querying the performance
counters 1K times per second, where the internal APIs could be hit millions of
times per second.)

If we're interested in compressed memory pages there are also ways to "estimate"
this by tracking the working set size of a particular system process. Ping me
directly for more info.

[bashi, 2017/05/08 05:52:00]

Thank you Chris for the detailed information. That's really helpful.

I glanced over startup_metrics_utils.cc and web sites which are linked from
comments in the file. I don't fully understand internal NT APIs and performance
counter APIs yet but I'll try to follow your suggestion, i.e. using performance
counter APIs to figure out which stats we should track then find corresponding
internal ones.

+  return nullptr;
+}
+
+}  // namespace content