New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 781360 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
teravest@chromium.org
sonnyrao@chromium.org
█ bccheng@chromium.org
cylee@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

tab discarder needs to run faster and to change its mind more readily

Project Member Reported by semenzato@chromium.org, Nov 3 2017 
(don't we already have a bug for this?  I can't find it)

In a high-load situation, the tab discarder fires too late, then keeps firing for a long time when it should no longer be firing.

The attached chart shows one such situation.  The data is from a 2GB cyan running a ToT build with a large number of open tabs, while I was switching tabs cyclically.

Each green-dotted vertical line shows when the kernel reports an OOM-kill in kmsg.

Each black-dotted vertical line shows when chrome creates the sad tab for the OOM-kill.

Each red vertical line is a tab discard.

Each blue vertical line corresponds to a low-memory notification being triggered.  The blue graph is "available RAM".  The horizontal blue line is the notification margin.

The green graph is free RAM, brown is free swap, hot pink is a 5-second moving average of tasks in the run queue (i.e. a 5-second load average).
figure_1.png
329 KB View Download

Comment 1 by semenzato@chromium.org, Nov 3 2017 

(forgot: x axis is time in seconds, y axis is various quantities scaled from 0 to 100, with the legend showing the scale)

Note that the first low-mem notification on the left is not recorded (my fault---I picked a too-narrow "window of interest"), but the first tab discard happens about 10 seconds after the low-mem fires.  That's way too late---kernel started OOM-killing after about 5 seconds.  Then the discards go on for 15 seconds when they really should not be happening because the available RAM is well above the threshold.

Eventually available memory falls below the threshold again, and we have a very similar behavior.

I wonder if we can play around with process priorities to speed this up.
►

Sign in to add a comment