lkml.org 
[lkml]   [1998]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.215 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site