diff options
| author | jamescook@chromium.org <jamescook@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-20 18:58:57 +0000 |
|---|---|---|
| committer | jamescook@chromium.org <jamescook@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-20 18:58:57 +0000 |
| commit | 4306df76b739842d6b8942b52549023dc7221938 (patch) | |
| tree | 3dd9ba98a6abb807c77907fb8bb3d76c2b21735d /chrome/chrome_browser.gypi | |
| parent | e6a638e12a4c95afc24812eeb0208e350206a0a0 (diff) | |
| download | chromium_src-4306df76b739842d6b8942b52549023dc7221938.zip chromium_src-4306df76b739842d6b8942b52549023dc7221938.tar.gz chromium_src-4306df76b739842d6b8942b52549023dc7221938.tar.bz2 | |
cros: Log per-process memory use on low memory events
We're seeing a lot of tab reloads caused by the tab discarder, but we're not sure yet where the memory is going. Dump the per-process private and shared memory use (same as the Task Manager columns) for Chrome processes when we hit low memory, such that we can see it in the system logs when users send us a feedback report. This adds tens of milliseconds to the delay between the low memory signal and the tab discard starting, but that isn't significant as we allow 750 ms for the discard to happen and the memory stats are collected asynchronously off of the UI thread.
Also refactor when we log UMA memory statistics - we used to do it every time we collected memory details, but with this change we need to be able to collect the details and skip additional UMA stats.
BUG=124038
TEST=browser_tests OomPriorityManagerTest, manual inspection of logs after triggering tab discard with about:discards
Review URL: http://codereview.chromium.org/10151005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133232 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/chrome_browser.gypi')
0 files changed, 0 insertions, 0 deletions