Messages in this thread | | | Date | Wed, 11 Nov 1998 23:27:04 +1100 | From | Richard Gooch <> | Subject | Re: Schedule idle |
| |
MOLNAR Ingo writes: > > On Tue, 10 Nov 1998, Gordon P. Oliver wrote: > > > _please_ We can do better than this. Only semaphores (not spinlocks) need > > to have the priority inheritance. [...] > > nope there are _not_ only semaphores, but many other types of locks.
Agreed.
> > [...] This can be done with lists off the > > semaphore and tasks... [...] > > it's _not_ easy to extend Linux semaphores to handle priority > inheritance. currently semaphore operations can be done via > hw-atomic test-and-set instructions. If we do anything more complex, > we cannot use simple instructions anymore. Linux semaphores are 2 > instructions for an up() and 2 for a down(), and thats one of our > crown jewels :)
Also agreed.
> the whole point is not quite valid, RT and filesystem IO doesnt mix > well anyway ... the solution: use system calls that are guaranteed > to not block, either by design, or by system policy (ie. separate > filesystem on a RAMDISK) ... or use a device that doesnt introduce > large latencies. (RAMdisk or solid state disk)
Agreed again. To me, this whole thread appears to have mixed a few different issues together with the resulting confusion. Here's a summary of my take on the various points raised:
- A high priority/important RT process should avoid touching the FS. Instead, a (lower priority) helper thread should do that.
- Nevertheless, the helper thread which touches the FS can be blocked from access if a SCHED_OTHER process bangs on the FS, which is not good.
- Similarly, a SCHED_IDLE process can block access to the FS for SCHED_OTHER or RT processes, which is also not good.
- I see this partly as an administrative problem: in normal life this problem does not occur. The normal method of dealing with a deliberate attack is to remove the gonads of the culprit.
- Remember there are many other ways of attacking the system, so let's not get hysterical about the possibilities of SCHED_IDLE.
- The "problem" (which I contend is not that important in real life) is due to a fundamental bug: calling schedule() while a resource lock is held. It is not a problem with different scheduling classes, although with different scheduling classes we can get permanent blocking (aka. deadlocks). Note that with a single scheduling class and manipulation of nice levels we can still get long blocking, which while not being a deadlock is still a performance loss.
- If we care about this issue, we have to deal with it at the source of the problem, and not point the finger at SCHED_IDLE or make spurious comments about the merits of the POSIX RT support in Linux. POSIX RT is here to stay and has it's merits (portability for one) even if it doesn't provide hard-RT. Using the fear of deadlocks as an argument against SCHED_IDLE, and even worse, as an argument for removing POSIX RT support, is really silly.
- Solutions like priority inheritance can solve these problems at the expense of an efficient semaphore.
- A simple solution of releasing a resource lock prior to calling schedule() and re-aquiring the resource lock after the call is cheap and effective.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |