1229159 - 172 MediaPlayback threads for page with 20 videos

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Eric Rahm [:erahm]]

Looking into bug 1220488 I noticed there were a ton of MediaPlayback threads present. The best I can tell we intend to use a shared "MediaPlayback" threadpool with a limit of 12 threads [1] (total, for the entire process).

STR:
#1 - Open firefox
#2 - Attach w/ gdb (if on e10s attach to content process)
#3 - run 'info threads', note small amount of threads, continue
#4 - Load test from bug 1220488, attachment 8691570 [details]
#5 - break in gdb, run 'info threads'

Below is a dump of the media related threads with the # of threads per name. We can see that there are indeed 12 decoder threads as intended. We can also see there are *many* duplicates of MediaPlayback threads present indicating that multiple threadpools with the name "MediaPlayback" are present. It's possible this can happen if the threadpool refcount goes down to 0 and it is released [2], while the threads themselves can remain around until they decide to shut down.

>      1 MediaPD~der #10
>      1 MediaPD~der #11
>      1 MediaPD~der #12
>      1 MediaPD~oder #1
>      1 MediaPD~oder #2
>      1 MediaPD~oder #3
>      1 MediaPD~oder #4
>      1 MediaPD~oder #5
>      1 MediaPD~oder #6
>      1 MediaPD~oder #7
>      1 MediaPD~oder #8
>      1 MediaPD~oder #9
>     25 MediaPl~ack #10
>      1 MediaPl~ack #11
>     25 MediaPl~ack #12
>      1 MediaPl~back #1
>     17 MediaPl~back #2
>     17 MediaPl~back #3
>     25 MediaPl~back #4
>     17 MediaPl~back #5
>     25 MediaPl~back #6
>      1 MediaPl~back #7
>      9 MediaPl~back #8
>      9 MediaPl~back #9

[1] https://dxr.mozilla.org/mozilla-central/rev/a18630f9ab42ddfde03ba8c7757a42069c48c7ed/dom/media/VideoUtils.cpp#257,260-262
[2] https://dxr.mozilla.org/mozilla-central/rev/a18630f9ab42ddfde03ba8c7757a42069c48c7ed/xpcom/threads/SharedThreadPool.cpp#143-147

Comment 1

[Jean-Yves Avenard [:jya]]

I wonder if it's related to JW (or was it Gerald's) changes a while back that will start a new thread if none are available to process a task.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Potentially dupe of bug 1205691?

JW worked on nsThreadPool in bug 1161405, he should be best placed to analyze this.

Comment 3

[Eric Rahm [:erahm]]

(In reply to Gerald Squelart [:gerald] from comment #2)
> Potentially dupe of bug 1205691?
> 
> JW worked on nsThreadPool in bug 1161405, he should be best placed to
> analyze this.

That seems possible, looking closer there are 12 unique MediaPlayback names. It is a bit disturbing that one playback thread could spawn 24 other threads though...

Other differences: in this case I'm looking at libav (mp4 playback, not webm) and the duplicate thread names are for playback, not decode.

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

checking.

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

I add some logs and run the test. Here are some observations:

1. there is only one nsThreadPool created with the name "MediaPlayback".
2. The nsThreadPool only creates 12 threads as specified by the pref "media.num-decode-threads".
3. the logs shows only 80+ threads are created through _PR_CreateThread (ptthread.c).

So we can conclude there are some threads created outside gecko code and this is probably a dup of bug 1205691.

Comment 6

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

WMF creates a lot of threads. We can probably limit the number of CPU cores we use for smaller sized videos.

Comment 7

[Kent Fredric]

At one point I had easily in excess of 30 media threads ( I'm guessing, too many to count, and had numbers as high as #180 ), all using between 5 and 15% CPU each, resulting in Firefox eating >200% CPU when all that was open was facebook and gmail.

I suspected facebook was doing something weird with notifications and threads, but it confuses me because facebook doesn't ever make any sound for me, and I can't see why I'd have 30 threads active for .... what?

It feels like there's something facebook does where it spawns a thread, but doesn't reap it again, and this belief is amplified by all those threads slowly evaporating after I unloaded the Facebook tab.

I've since gone through my about:config and disabled everything I can think of that relates to mediaplayback, and those problem threads have yet to return, but there aught to be a clearer path here to avoid this problem, because "Firefox eats 2-or-more entire CPU cores to do nothing in the background" is not great. ( Apologies if this is unrelated, this seems to be as related as I can find, and I don't know how to more clearly file an explicit bug for this if it is unrelated )

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3