[Bug dynamic-link/19917] Bad threading regression starting with f3dcae82d54e5097e18e1d6ef4ff55c2ea4e621e

["glibcbugs0001 at cneufeld dot ca" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19917

--- Comment #4 from Christopher Neufeld <glibcbugs0001 at cneufeld dot ca> ---
This looks to be more subtle than some slow mutex locking.  I built a new
ffmpeg with debugging symbols, and ran it under gdb and glibc-2.23.  I then
sent SIGINT several times, each time looking at the threads.  There are 15
threads while ffmpeg is transcoding the file, but only 4 of them, threads 8-11,
are libx264 threads.  The others are all sitting in pthread_cond_wait.S:185. 
Occasionally I was able to catch one of the 4 x264 threads in a
pthread_cond_wait, but not nearly often enough to justify a 6-fold decrease in
throughput.

It's not an input/output throttling issue, because if it were, I wouldn't be
running my 4 cores flat out, there would be idle time on the CPUs.

I am continuing to investigate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.