Memory Usage Bug: Android KGSL Memory not released even after closing all tabs
Reported by
sardas...@gmail.com,
Apr 10 2016
|
||||
Issue descriptionChrome Version: 49.0.2623.105 OS: Android 6.0.0 Total RAM : 2 GB Stock Android : No Third Party UI skin bloats Can you reproduce this memory bloat? Yes What steps will reproduce this memory bloat? (1) Freshly Reboot Android Device and wait for 5 mins for the system to get stable. (2) Keep tracking KGSL memory as well as Total memory via dumpsys in the background with adb shell during the whole experiment. (3) Default setting on chrome for tabs is "MERGE TAB AND APP --> OFF". Keep the same setting. (4) Launch a TAB with a simple website (any simple website). The PSS memory usage as well as KGSL memory usage increases. Keep adding TABS one by one. Increase in memory observed (which is natural). (5) At some point the maximum number of tabs that are alive (not loading website again on going to that tab) are 7-8 Tabs. Press Home Button. Again launch chrome. The tabs are still alive on chrome. (6) After reaching this concurrency, number of tabs start falling. /dev/kmsg observed for kill messages. (7) Loop through the opened tabs one by one and launcher process (home button), the number of alive tabs fall further again. However, the KGSL memory consumption don't fall down. (8) Continue Looping with alive tabs (3-4 at some stage) and home button -> tab1, tab2, tab3, tab4, home. The KGSL memory didn't fall although only 4 tabs are alive. The number of tabs fall further to 2 tabs when looping. The KGSL memory by chrome is still equal to 8 tabs though only 2 tabs are alive. (9) At one point, the number of alive tabs fall to 0. Still the KGSL memory of chrome process (privileged process) is as high as 400-450 MB (which was equal to when 8 tabs were alive). (10) So even if there is no TAB alive currently, around 450 MB of memory is still held by chrome process. This kills other background process/services. Ideally chrome should have released this memory when tabs are closed/killed. (11) At this stage when chrome is pushed in background, the KGSL memory falls down, but when launched again, the KGSL memory shoots again to 450 MB, which is very huge requirement at one shot. This causes other process/services getting killed unnecessarily. (12) THIS BEHAVIOR OF CHROME IS NOT OBSERVED WHEN THE SETTING IS CHANGED "MERGE TAB WITH APP --> ON". (13) My gut feeling is when tabs are not merged with apps, chrome is treated as single process within which tabs are sub process. When tabs increase, the whole chrome process KGSL memory usage increases by (number of tabs * ~KGSL memory for each tab). But when tabs are merged with apps, each tab is treated as individual process and KGSL memory of chrome:privileged process doesn't increases hugely. (14) This behavior is not observed with other browsers. Attaching logs with dumpsys and KGSL logs. Also attaching PID (ps) logs alongwith /sys/class/kgsl/kgsl/page_alloc logs. PID.txt corresponds to kgsl_live.txt(values in Bytes) at given time PID_2.txt corresponds to kgsl_live_2.txt (values in Bytes) PID_3.txt corresponds to kgsl_live_3.txt (values in Bytes) I dug more into the details and hence spotted KGSL as issue. Attaching relevant logs. Couldn't follow JSON method of collecting logs for now to eliminate any disturbances due to other process (textpad, etc) getting launched on Android device. Please note that above experiment was done in one shot - dumpsys meminfo and kgsl_C.txt were collected continuously. Only PID* and kgsl_live* were collected at intervals. Clearly, it can be seen that at the end of experiment, there was no tab alive (no chrome:sandbox process), but still the KGSL memory occupied by chrome:provileged process was as high as 450 MB. See PID_3.txt and kgsl_live_3.txt file for this. Did someone just forgot to write a free() on closing tab?
,
Apr 13 2016
,
Apr 21 2016
,
Apr 24 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 24 2017
Issue still exist |
||||
►
Sign in to add a comment |
||||
Comment 1 Deleted