> One of two things:
> 1) The higher priority task will no longer be runnable; or
> 2) We gave enough rope to hang yourself, and, well, you did.
and (3) the lower priority task won't be runnable either.
Without addressing this (and it is addressable, see below) this feature
won't make it into the kernel. It isn't an argument to say "we gave you
the rope and you took it" because if I idle task some random application
because it deserves little time, I shouldn't have to think of what
resource/kernel semantics it and another task are going to get into a
priority inversion fight over.
I've seen a few solutions. The easiest is to just give idle tasks a
"boost" on occasion to give them a chance to prevent the deadlock. You
then, however, have the problem where the tasks can take advantage of
the boost... Or, we could fix in-kernel deadlocks by doing priority
inheriting on locks held by A and wanted by B (i.e., if A holds
something B wants, boost A's priority temporarily to that of B's). But
that is probably overkill ... note to do any of these it is probably
cleanest to make a SCHED_IDLE scheduling class.
maybe I'll put a patch together ...
Robert Love
-
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/