New issue
Advanced search Search tips

Issue 772986 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

is the chrome tab discarder logging too much?

Project Member Reported by semenzato@chromium.org, Oct 9 2017

Issue description

Tab discarder logging seems unreasonably heavy-weight, to the point that it may be impacting discard decisions and speed.  For instance:

[12657:12657:1009/033026.562854:WARNING:oom_memory_details.cc(46)] Tab Discards Memory details (852 ms):
Tab [Oklahoma City News, Sports, Weather & Entertainment | News OK] 1919 MB private, 1923 MB shared, 427 MB swapped, 163 FDs open of 2048
Browser 708 MB private, 711 MB shared, 651 MB swapped, 515 FDs open of 8192
Tab [Google Keep] 268 MB private, 270 MB shared, 266 MB swapped, 94 FDs open of 2048
GPU [] 198 MB private, 199 MB shared, 191 MB swapped, 192 FDs open of 8192
Tab [CNN Travel | Global Destinations, Tips & Video] 188 MB private, 190 MB shared, 186 MB swapped, 85 FDs open of 2048

... (rest of list omitted)

Immediately followed by another list with some more info:

[12657:12657:1009/033026.575371:ERROR:device_event_log_impl.cc(156)] [03:30:26.573] Memory: tab_manager_delegate_chromeos.cc:636 List of low memory kill candidates (sorted from low priority to high priority):
[12657:12657:1009/033026.575719:ERROR:device_event_log_impl.cc(156)] [03:30:26.575] Memory: tab_manager_delegate_chromeos.cc:639 tab New Tab, renderer_handle: 0, oom_score: -1001, is_discarded: 1, discard_count: 2, last_active: 79879072129 bogo-microseconds, process_type BACKGROUND_TAB

... (rest of list omitted except last line:)

[12657:12657:1009/033026.592441:ERROR:device_event_log_impl.cc(156)] [03:30:26.592] Memory: tab_manager_delegate_chromeos.cc:646 Target memory to free: -146432 KB

this starts at 562 (milliseconds) and ends at 592, so it's 30ms.  Granted this is not a frequent event, but 30ms seems an eternity just for logging some info which is mostly not very useful, and also has a lot of duplication.

Also, in this case memory was freed (maybe OOM kill?) between the low-mem notification and figuring out how much memory needs freeing.  Otherwise there may be additional logging.


 
We're still polling for low memory events, right? That seems like a much bigger impact on responsiveness than latency from writing log messages.

I agree that a lot gets logged, though I have found information like renderer_handle, is_discarded, and discard_count to be helpful when debugging.
yes we're still polling -- I had the event based version prototyped a while back, but haven't gotten back to finishing implementation -- will do that  at some point

Sign in to add a comment