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.
Ludo.
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 21:00:24 EST