![]() | |||||||||||||
Messages in this thread |
On Fri, 2005-05-13 at 20:26 +0200, Ingo Molnar wrote: > 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 > OK, Forget about vanilla, I'm keeping to your kernel now ;-) In finish_task_switch, where is need_resched set? > _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. No this wasn't from real world applications yet. So the bug may rightly be with the placement of my timers. I was looking at the code and didn't know how the reschedule takes place and started testing it. Let me know where that need_resched is with that finish_task_switch code, and I'll probably be happy with just that. Thanks, -- Steve - 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/ | ||||||||||||
| Last update: 2005-05-13 21:13 [from the cache] ©2003-2008 | |||||||||||||