Messages in this thread | | | Date | Wed, 7 Mar 2001 20:20:27 +0100 | Subject | Re: static scheduling - SCHED_IDLE? | From | Oswald Buddenhagen <> |
| |
> 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 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/
| |