It is clear that the behavior of lat_ctx bypasses almost all of
the scheduler's attempts at CPU affinity. The real question is,
"How often in running 'real workloads' are the schduler's attempts
at CPU affinity bypassed?".
When encoding mp3s on a dual processor system, naturally I try to
encode two at once.
Most of the time this works as expected, one processed more or less
sticks to each CPU. However, I have noticed that if for some reason,
a third process has to be scheduled (which is inevitable if you
actually want to do anything), then these two processes seem to bounce
back and forward for a few seconds, _even_ after this CPU spike has
gone.
Now, I'm not sure if I'm imagining this or not, as I said, I have two
CPUs and two CPU-bound tasks, to instrument this as all, I really have
to affect what I am looking at (rather like the uncertainty principal)
so I assumed that perhaps my programs to read and process
/proc/<n>/cpu was simply eating several cycles and each process was
yielding more or less at random causing what I saw seeing.
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/