Messages in this thread | | | Date | Sun, 11 Jun 2006 08:37:46 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH -rt] Priority preemption latency |
| |
* Ingo Molnar <mingo@elte.hu> wrote:
> i slept on it meanwhile, and i think the safest would be to also do > the attached patch ontop of -rt3. This makes the 'kick other CPUs' > logic totally unconditional - so whatever happens the wakeup code will > notice if an RT task is in trouble finding the right CPU. Under -rt3 > we'd only run into this branch if we stayed on the same CPU - but > there can be cases when we have your scenario even in precisely such a > case. It's rare but possible.
just to elaborate on that possibility a bit more, it's this portion of the wakeup code that could cause problems:
new_cpu = wake_idle(new_cpu, p); if (new_cpu != cpu) { set_task_cpu(p, new_cpu); task_rq_unlock(rq, &flags); /* might preempt at this point */ rq = task_rq_lock(p, &flags); old_state = p->state; if (!(old_state & state))
at the 'might preempt' point the kernel can go to any other CPU. The stock kernel does not care because it's really rare and wakeup placement of tasks is a statistical thing to it. But for RT it's important to get it right all the time, so my patch removes the RT-overload check from the else branch to an unconditional place. (I doubt you can trigger it normally, but it's a possibility nevertheless.)
(i'll do a patch for the upstream scheduler to not re-enable interrupts at this point [it's a waste of cycles], but even if we couldnt go to another CPU the whole scheduling scenario might change while we are trying to acquire the runqueue lock, so it's still beneficial to have the RT-overload check unconditional.)
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/
| |