Messages in this thread | | | From | Zdenek Kabelac <> | Subject | Re: static scheduling - SCHED_IDLE? | Date | Thu, 8 Mar 2001 11:17:39 GMT |
| |
ludovic wrote: > > Oswald Buddenhagen wrote: > > > > > 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. > > > > Since the linux kernel is not preemptive, the problem is a little > bit more complicated; A low priority kernel thread won't lose the > CPU while holding a lock except if it wants to. That simplifies the > locking problem you mention but the idea of background low priority > threads that run when the machine is really idle is also not this > simple.
You seem to have a sence for black humor right :) ? As this is purely a complete nonsence - you were talking about M$Win3.11 right ? (are you really the employ of Sun ??)
- 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/
| |