lkml.org 
[lkml]   [2006]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-07-06 15:43    [W:0.061 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site