On Sat, 2013-03-16 at 17:10 -0700, notgeorge burns wrote: > Just curious, what is the rationale for irq_default_primary_handler() > not to invoke set_need_resched()? Drivers that set up with plain-old > request_irq() will have a scheduled softirq handler, but the hardirq > will return to wherever it was without the priority of the softirq > task coming into play. For my drivers I can work around it with > request_threaded_irq() but is the potential inversion for > request_irq()-installed handlers really the expected behavior? Sorry > if this question has been gone over before, I couldn't find anything > with a quick search of the archives. Why should it invoke set_need_resched(), I hope your driver isn't doing that, as it may not get scheduled, and you just added the extra overhead of a unnecessary schedule() call. If a hardirq wakes up its thread, and that thread happens to be of a higher priority than the currently running task, the act of waking up will set need_resched for you. But it can certainly be possible for the current userspace thread to be running at a higher priority than the interrupt thread, and we don't want to call schedule in that case. This is the point of -rt in the first place. Its OK to have some userspace tasks higher priority than interrupts. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
