On Sun, 2010-02-28 at 20:26 +0100, Raistlin wrote:
quoted text
> Therefore, as of now, this patch:
>  - implements priority inheritance for -deadline tasks, according to
>    what described above;
>  - to make this possible without rewriting outstanding chunks of
>    code of both -deadline scheduling and existing PI, the task's
>    relative deadline is stored in the prio field of the task_struct.
>    This is done in such a way that:
>     * prio is always < 0 for -deadline tasks,
>     * p1->prio < p2->prio still means p1 has higher priority than
>       p2, i.e., in our case, p1 has smaller relative deadline.
>  - the point above means that, since prio is of int type, a relative
>    deadline has to be smaller than INT_MAX. This is about 2sec,
>    which is a something (we think! :-)) we can afford, at least
>    for now.

Right, except that this makes the plist stuff O(INT_MAX) [ or rather
O(nr_dl_tasks) ].

But I guess it serves for testing.

I think it would be relatively straight forward to modify the existing
PI chain code to work using an RB-tree instead of the plist stuff.

An RB-tree would also make the whole ->prio mess much easier to solve,
we could simply make a more complex comparison function, like:

int rt_mutex_prio_less(struct task_struct *left, struct task_struct *right)
{
	if (left->prio < right->prio)
		return 1;

	if (left->prio == right->prio && left->prio == -1) {
		if (left->deadline < right->deadline)
			return 1;
	}

	return 0;
}

Which uses the static prio -1 to represent all deadline tasks.

quoted text
>  - disables bandwidth throttling for tasks while they are deadline
>    boosted. It also tries to make them pay back for runtime overrun
>    and deadline misses in this phase, but it's only "local", in the
>    sense that instances farther than the one right next to the
>    overrun are not going to be direcly affected.
> 
Yeah, good enough to start with ;-)

--
unsubscribe notice
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/