* Ingo Molnar <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
