Alan Cox writes:
>> This is what makes Ingo's latency patch less dangerous: need_resched is hard
>> to set. Your scenario requires that an interrupt routine, interrupting
>> kernel mode, set needs_resched. Where does this happen?
>
>A process wake from interrupt state - eg a network event. Its not actually
>that uncommon. The window is small however so it isnt likely to get hit
>much.
Lets talk about audio interfaces too. With a 1.5ms fragment size, we
potentially have a SCHED_FIFO task that wants to get running again 13
times per timer interrupt. If the task only does a few 100usec of work
when it wakes up (not uncommon) and then goes back to sleep, the
window here is big, if I understand Alan's use of the term.
Ditto for a task using the async I/O capabilities of the RTC driver,
and a moderate-to-high interrupt frequency from the RTC.
Ditto for a task waiting for data from a MIDI interface, woken during
the interrupt handler for the device.
Basically, ditto for any situation where a task sleeps on the
condition of an external device/interface, wants to respond in a soft
real time fashion to the change, and rarely, if ever, is still
runnable before the next such interrupt shows up. This is true for a
lot of audio apps.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:33 EST