[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 #6 from Christopher Neufeld <glibcbugs0001 at cneufeld dot ca> ---
Created attachment 9162
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9162&action=edit
Output of perf stat -t <PID>

More exploration of the issue.  I ran my transcoding job against libc-2.23 and
against libc-2.21.  Then, on the four worker threads in each case, I collected
about five seconds of data with 'perf stat -t <PID>'.  The outputs are in this
attachment.

Notable differences: in the slow run, two threads are scheduled at relatively
high fractions, .90 and .88, but they have a high number of stalled cycles per
instruction, and very few instructions per cycle.  They also have a relatively
low branch rate.  The other two threads are scheduled at much lower fractions,
0.024 and 0.006, but have relatively higher instructions per cycle, and far
fewer stalled cycles per cycle.  They also have a much higher branch rate.

In the fast run, there are still two threads that get most of the scheduling,
at 0.64 and 0.67.  Now, though, they have much higher instruction per cycle
counts, far fewer stalled cycles per instruction, and a much higher branch
rate.  The other two threads, at 0.275 and 0.059 scheduling, also have
relatively high instruction per cycle rates, low stalled cycles per
instruction, and high branch rates.

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