Ingo Molnar wrote:
>
> since there is lots of idle CPU time left, the only thing that could make
> a difference is timeslice length.
> to 'fix' this (temporarily), renice all the non-SCHED_FIFO processes to
> nice +19, that will give them the minimum timeslice length.
That caused a "choke" effect of about 10 seconds and then returned back to
normal without visible change.
> again, what does it need to cause the 'bad' situation - too much latency
> in the sound delivery path causing the audio buffers to starve? (or audio
> buffers to be dropped?)
If processes doing read()/write() on socket are not scheduled fast enough it
will cause sender thread in distributor process (SCHED_FIFO) to loose
pthread_cond_*() event for new block of data. This is non-waiting datablock
posting mechanism is made to prevent one hung or otherwise nonresponding
process from affecting other processes dataflow, esp. in SMP systems. So all
the output threads must be back from write() on pthread_cond_wait() before
input thread finishes it's read() and issues pthread_cond_broadcast() for
new datablock. If one of those output threads is not on pthread_cond_wait()
it will of course loose it's datablock.
I made even more testing and found situation where the old scheduler also
does same thing. It seems to be related to processes frequency(/size) of
issuing read()/write() calls on socket. Below _and_ above this frequency
everything works fine. This frequency is a bit lower on old scheduler. So
there is some kind of grey frequency region.
- Jussi Laako
-- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers- 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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:56 EST