Memory cleanup

[Harisha Navilarekallu]

Hi,

We have Blink running on a Mips based platform.

When I try to run YouTube Leanback, I face memory related issues.
As and when I move from one video to other, I see that memory usage keeps on increasing. Since our platforms have limited memory, we cannot afford lots of memory.
The render, which starts with around 60MB of poster page (First page of YTL), reaches more than 300MB (VmRSS) by around 15th Video. For every video, it increases by around 15MB. We need not play full video, but jumping to next video after 2 seconds we see the issue.

(Note that it happens only during MSE based playback and otherwise we have not seen such huge raise in memory.)

Initially thought it might be due to JS, so even tried running with --max_old_space_size limit. But it didnt help.
So was checking the maps for the renderer process.

For each video played, I see two types mapping :
First one:
20921000-2093f000 rw-p 00000000 00:00 0
2093f000-20a60000 ---p 00000000 00:00 0
..
..

Second one:
613f8000-617f9000 rw-s 00000000 00:13 12576      /dev/shm/.org.chromium.Chromium.0TEJF5 (deleted)
617fa000-61bfb000 rw-s 00000000 00:13 12342      /dev/shm/.org.chromium.Chromium.pp17RI (deleted)
..
..

Shared memory, I see that one place it gets generated is "audio_sync_reader.cc". Since I dont see the files in "/dev/shm", its already deleted and hence we see the deleted.
But the question if we can free up after the use? Where can I look into for more memory optimized way?
Any suggestions?

Thanks

[วีสัน ทำมะ]

เมื่อ 12 ส.ค. 2017 1:00 AM "Harisha Navilarekallu" <hnav...@cisco.com> เขียนว่า

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24358dd0-c71f-48cc-b1cc-89d153a860f9%40chromium.org.

[Primiano Tucci]

You should first use the devtools heap profiler (see this doc) to figure out if the memory is retianed from the content. If so there is very little we can do.

If not (by looking at your descriptions, this seems to be a problem outside of the content) you should grab traces as indicated by this doc. There is quite some instrumentation inside of chrome that can help diagnose memory issues and understand which components of chrome use memory.

From what you describe it seems we are somehow leaking shared memory segments. Given the unusual platform, I wouldn't be too surprised if you are hitting either some gpu driver bug, or some bug in our graphics or media pipelines which happens only on that platform.

The fact that underlying files are deleted is irrelevant. As long as we keep them mmaped they will be kept refcounted in the kernel. So the actual bug might be about leaking shared memory segments during video playback.

If you find anything useful please consider filing a bug on crbug.com with traces and repro steps if possible.

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24358dd0-c71f-48cc-b1cc-89d153a860f9%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-oYKnJfao1f56GfcoCX5PtwKEt4asLRRLVw6BqHVKHnwQHdA%40mail.gmail.com.

[Harisha Navilarekallu]

Thanks for the info.
Forgot to mention that, I use content_shell and not chrome.

On Friday, August 11, 2017 at 11:51:29 PM UTC+5:30, Primiano Tucci wrote:

You should first use the devtools heap profiler (see this doc) to figure out if the memory is retianed from the content. If so there is very little we can do.

If not (by looking at your descriptions, this seems to be a problem outside of the content) you should grab traces as indicated by this doc. There is quite some instrumentation inside of chrome that can help diagnose memory issues and understand which components of chrome use memory.

Checked with dev-tools, but seems to be OK with JavaScript heap profiling. Since I dont use chrome, all the things are not available.
 

From what you describe it seems we are somehow leaking shared memory segments. Given the unusual platform, I wouldn't be too surprised if you are hitting either some gpu driver bug, or some bug in our graphics or media pipelines which happens only on that platform.

The fact that underlying files are deleted is irrelevant. As long as we keep them mmaped they will be kept refcounted in the kernel. So the actual bug might be about leaking shared memory segments during video playback.

If you find anything useful please consider filing a bug on crbug.com with traces and repro steps if possible.

Sure, if I find anything will file a bug.
 

[วีสัน ทำมะ]

เมื่อ 16 ส.ค. 2017 3:20 PM "Harisha Navilarekallu" <hnav...@cisco.com> เขียนว่า

[kirkpatr...@gmail.com]

[kirkpatr...@gmail.com]

On Friday, August 11, 2017 at 2:00:38 PM UTC-4, Harisha Navilarekallu wrote:

[kirkpatr...@gmail.com]

On Friday, August 11, 2017 at 2:00:38 PM UTC-4, Harisha Navilarekallu wrote: