On Thu, 6 Jul 2006, Ingo Molnar wrote:
* Esben Nielsen <[email protected]> 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.)
I think that is more or less what my patch does...
Esben
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]
