Messages in this thread | | | Date | Fri, 13 May 2005 20:26:31 +0200 | From | Ingo Molnar <> | Subject | Re: Does smp_reschedule_interrupt really reschedule? |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> As the comment says, do nothing since all the work is automatically > done at the return from interrupt. But is it? Doesn't the > need_resched need to be set? Here's what I'm seeing with Ingo's > kernel. I capture the time in sched.c when the > smp_send_reschedule_allbutself is called, and also a capture of the > time when the schedule actually takes place. I'm finding differences > up to 2 tenths of a second. That's TENTHS! I added the following > patch:
it's all a bit tricky. The short story is that i think both vanilla and -RT kernels are fine.
Here is how smp_send_reschedule() is used:
CPU#0 CPU#1
set_tsk_need_resched(rq->curr); ... smp_send_reschedule() --- IPI ---> smp_reschedule_interrupt(); ... entry.S's need_resched check
_but_, this is intentionally racy: if CPU#1 happens to reschedule before the IPI reaches CPU#1 (an IPI can take 10 usecs easily so the window is not small), then need_resched might be cleared before the IPI hits. In that case you wont get a reschedule after the IPI hits, because it was done before!
so the correct thing to measure is what the -RT kernel's wakeup-latency timing feature does: the time from setting need_resched, to the point the task starts to run. The feature works on SMP too - and it doesnt show any large latencies.
are you seeing actual process delays? If not then i think those large latencies are just the result of the wrong assumptions in your measurement code.
Ingo - 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/
| |