> The problem with these things it that sometimes such a task may hold
> a lock, which can prevent higher-priority tasks from running.
>
true ... three ideas:
- a sort of temporary priority elevation (the opposite of SCHED_YIELD)
as long as the process holds some lock
- automatically schedule the task, if some higher-priorized task wants
the lock
- preventing the processes from aquiring locks at all (obviously this
is not possible for required locks inside the kernel, but i don't
know enough about this)
> A solution would be to make sure that these tasks get at least one
> time slice every 3 seconds or so, so they can release any locks
> they might be holding and the system as a whole won't livelock.
>
did "these" apply only to the tasks, that actually hold a lock?
if not, then i don't like this idea, as it gives the processes
time for the only reason, that it _might_ hold a lock. this basically
undermines the idea of static classes. in this case, we could actually
just make the "nice" scale incredibly large and possibly nonlinear,
as mark suggested.
best regards
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Nothing is fool-proof to a sufficiently talented fool.
-
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/
