Why does preemption patch make a difference for me, then? I'm not doing
anything even remotely close to real-time processing.
> As Alan noted for the ring of dma fragments to expire you need a
> scheduler latency of the order of seconds, now (assuming the ll points
> in read/write paths) when we've bad latencies under writes it's of the
> order of 10msec and it can be turned down further by putting preemption
> checks in the buffer lru lists write paths.
Isn't mp3 decoding done `just in time' ie we decode x and buffer x,
decode y and buffer y...hopefully in a quick enough manner it sounds
like coherent sound? Thus, if the task can not be scheduled as
required, there are noticeable latencies in the sound not because the
sound card buffer ran dry but because the mp3 couldn't even be decoded
to fill the buffer!
Anyhow, if we have latencies of 10ms (and in reality there are higher
latencies, too), these can cause the sort of system response scenerios
that are a problem. Preemption makes these latencies effectively 0
(outside of locks).
Robert Love
-
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/