Re: Does smp_reschedule_interrupt really reschedule?

[Ingo Molnar <mingo@elte.hu>]

* 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/