Messages in this thread | | | Date | Thu, 6 Jul 2006 15:32:38 +0200 | From | Ingo Molnar <> | Subject | Re: New PriorityInheritanceTest - bug in 2.6.17-rt7 confirmed |
| |
* Esben Nielsen <nielsen.esben@googlemail.com> wrote:
> It can run within try_to_wake_up(). But then it the whole lock chain > is traversed in an atomic section. That unpredictable overall system > latencies since the locks can be in userspace. So it has to run in > some task. That task has to be high priority enough to preempt the > boosted tasks, but it can't be so high priority that it bothers any > higher priority threads than those involved in this. So it can't be, > forinstance a general priority 99 task we just use for this. We thus > need something running at a slightly higher priority than the priority > to which the tasks are boosted, but not a full +1 priority. I.e. we > need to run it at priority "+0.5".
we could just queue the task in front of the other task in the runqueue, and mark that task for reschedule if it's running currently. (Doing this is not without precedent: we do something similar in wake_up_new_task() to implement child-runs-first logic.)
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/
| |