Messages in this thread | | | Subject | Re: scheduler ignores need_resched flag in 2.2.x and 2.3.x? | Date | Tue, 21 Mar 2000 10:13:27 -0500 | From | Paul Barton-Davis <> |
| |
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/
| |