That might be what you're seeing. I believe with Code Purple Chrome started freeing tabs on critical memory pressure events but I discovered earlier this year that freeing memory at this time on desktop can make things much worse (driving the machine to thrash) - https://docs.google.com/document/d/10jRpINSqWgzUk1fITxm65w5tVUZ_YJc-W1onbz4jqME/edit#heading=h.8jxmsx4qso8b .

We're currently moving towards a "memory coordinator" system that will try to free up resources before the onset of memory pressure.

Per the discussion on chrome-memory@, this seems like a regression introduced recently. We should probably identify the culprit CL and consider reverting it.

Anyone wants to take ownership of this?

It seems likely the culprit is
https://codereview.chromium.org/1587273002
which seems like it would have had the effect of noticing memory pressure earlier.

If this is indeed the culprit, I think it adds weight to my theory that we should not be trying to do this at all on virtual memory systems unless we can be REALLY smart about it.

I'm going to put together an experiment to disable the renderer broadcast to see how the metrics look.

https://codereview.chromium.org/1587273002 should not be causing this problem. While it is true that it now allows the Memory Pressure Monitor to monitor memory pressure in realtime, this was specifically to benefit UMA so that we could accurately monitor how long the machine stayed in various memory pressure states.

I was specifically mindful of the fact that taking action right at the moment memory pressure changed was a bad thing. It was already bad enough that we took action in response to memory pressure change notifications from the OS, which are delayed up to 60s from the pressure change event. I specifically avoided generating a memory pressure change notification upon detecting a realtime change in memory pressure, instead leaving the system as it was to trigger off of the delayed pressure change events from the OS. Please see my comment in MemoryPressureMonitor::OnMemoryPressureChanged().

A leaking application may make the handling of memory pressure even worse i.e. we would try to shrink down memory but cannot because we cannot free up resource and re-try. The leak in https://bugs.chromium.org/p/chromium/issues/detail?id=717474 may have flushed out such an issue issue.

Can we reproduce this issue? Step (1) and (2) are my regular working setup on my MacBook. I tried to drive my machine into this heavy CPU state but I cannot reproduce. Note that crbug/717474 is fixed now.

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

commit 37c4e81eb4dfa713a06164dbce721710b92b2ca9
Author: brettw <brettw@chromium.org>
Date: Mon May 15 23:20:15 2017

Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under memory
strain. But when the system is under memory strain, garbage collecting makes thrashing
worse. When we're under memory pressure, waking up the least-recently-used renderer
and making it touch a lot of its memory by GC-ing will likely page in that renderer.

The current system does this for all renderers repeatedly (one every two seconds, looping
back to the least-recently-used one again) until there is no more memory pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory pressure events
and may clear some caches, but the renderers will not. They will presumably get paged
out like normal processes. This affects only desktop systems. A separate memory pressure
system exists on Android, and the messages were already disabled on ChromeOS due to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=mbarbella@chromium.org (security IPC review for messages removal)

Review-Url: https://codereview.chromium.org/2882513004
Cr-Commit-Position: refs/heads/master@{#471942}

[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/chrome/browser/memory/tab_manager.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/chrome/browser/memory/tab_manager.h
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/chrome/browser/memory/tab_manager_unittest.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/chrome/browser/memory/tab_stats.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/chrome/browser/memory/tab_stats.h
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/browser/BUILD.gn
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/browser/browser_child_process_host_impl.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/browser/devtools/protocol/memory_handler.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/browser/memory/memory_message_filter.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/browser/memory/memory_message_filter.h
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/browser/memory/memory_pressure_controller_impl.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/browser/memory/memory_pressure_controller_impl.h
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/browser/memory/memory_pressure_controller_impl_browsertest.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/child/BUILD.gn
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/child/child_thread_impl.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/child/memory/child_memory_message_filter.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/child/memory/child_memory_message_filter.h
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/common/BUILD.gn
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/common/content_message_generator.h
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/common/memory_messages.h
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/public/browser/BUILD.gn
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/public/browser/memory_pressure_controller.cc
[delete] https://crrev.com/25ac3c481a621cec69d1dec92abb7efee9a33d27/content/public/browser/memory_pressure_controller.h
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/content/test/BUILD.gn
[modify] https://crrev.com/37c4e81eb4dfa713a06164dbce721710b92b2ca9/ipc/ipc_message_start.h

Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.

Available, but no owner or component? Please find a component, as no one will ever find this without one.