Open Bug 1496554 Opened 7 years ago Updated 5 months ago

MediaDecoder threads can contend on the allocator lock too much

Categories

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

enhancement

Tracking

()

Performance Impact low
Tracking Status
firefox64 --- affected

People

(Reporter: jesup, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, perf:responsiveness)

See bug 1496096 - decoding many videos at once there causes massive allocator lock contention. Using the debug patch there in gdb, and breaking 10s apart to monitor the atomics shows a 45% contention rate in the content process. This means 45% of the time jemalloc tries to lock a mutex, it's owned by someone else and we'll have to wait (spin or otherwise). Mutex contention at this rate can slow progress to a crawl. And in other profiles there we see up to 40+ % of the time spent in lll_lock_wait, lll_unlock_wake, pthread_mutex_lock directly, etc. We should a) try to avoid allocating so much, and b) use per-thread arenas like Stylo does (see https://searchfox.org/mozilla-central/source/layout/style/ServoBindings.cpp#2765)
Whiteboard: [qf:p1]
Rank: 15
Priority: -- → P2
QA Contact: drno
QA Contact: drno
Whiteboard: [qf:p1] → [qf:p1:responsiveness]
Whiteboard: [qf:p1:responsiveness] → [qf:p3:responsiveness]
QA Whiteboard: qa-not-actionable
Performance Impact: --- → P3
Whiteboard: [qf:p3:responsiveness]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.