973705 - Reduce size of media decode thread pool

Status: RESOLVED WONTFIX

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

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

We should investigate reducing the number of threads in the decode thread pool. This will reduce the virtual address space we reserve for threads' stacks, and hopefully reduce the overhead of thread-context switches.

The problem we face is that we currently do blocking reads on our decode threads. So if we're running low on downloaded data to decode, we'll block one of our threads until the download progresses. So one thread per core is not the best approach in the sort term.

I think we can do a few things to mitigate this for now:
* Only run a decode task if X bytes of downloaded data is available for reading at the MediaResource's current read cursor. This won't apply for seek task obviously.
* Count the number of threads blocked in MediaResource::Read(), and when that number approaches the number of threads in the thread pool, increase the size of the thread pool up to some upper limit.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

I tried using (4 + num_cores*1.5) threads, and saw a spike in random orange:
https://tbpl.mozilla.org/?tree=Try&rev=6742a74a9a6d

I had not done anything to handle the situation where all threads were blocked by I/O.

Perhaps elements that are going into the bfcache are blocking on I/O and not releasing the threads?

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

It's probably worth looking at this again, but I think it would make sense in another bug, as most of the issues in comment 0 are no longer valid.