Messages in this thread | | | Date | Thu, 15 Jul 1999 17:23:13 +0200 | From | Sven Heursch <> | Subject | Re: SCHE_RR/FIFO |
| |
Andi Kleen wrote:
> Sven.Heursch@unibw-muenchen.de (Sven Heursch) writes: > > > "Stephen C. Tweedie" wrote: > > > > > Hi, > > > > > > On Wed, 14 Jul 1999 14:28:14 +0200, Sven Heursch > > > <Sven.Heursch@unibw-muenchen.de> said: > > > > > > > Could it be that the scheduler in the kernel 2.2 has problems with the > > > > priority based scheduling algorithm SCHED_FIFO and SCHED_RR. The > > > > verification was made with two concurrent running processes with the > > > > real time priorities 30 and 99. Normaly the higher one should be > > > > scheduled first. But in Linux 2.2 that do not happend evereytime. > > > > > > What test case breaks the rule for you? The scheduler's goodness > > > function should still absolutely prefer non-SCHED_OTHER processes. > > > > Yes, indeed, the kernel source code says so! But the reality is different. > > For example: > > We have two processes, A & B. A has the priority 99, B the priority 30. Both > > are the only processes which are scheduled with SCHED_FIFO in the system. > > Process A starts and goes in nanosleep(). Now B got the CPU and does for > > example the access() system call. After a few micorseconds, an interrupt is > > generated and interrupts the process B. Process A has installed an > > interrupthandler for that interrupt before and is beeing signaled by the > > ISR. > > You mean it called a kernel function to install an interrupt handler, > and the handler does a send_sig() ?
yes, process A installs an interrupt handler and that one calls from inside the kernel the kill_proc() syscall to send a signal.
> > > > Now the crazy thing: Wheather A has the highest priority in the system and > > is now runnable, process B is being scheduled after the ISR in Kernel 2.2. > > Process A is sleeping on. > > So it is never waken up, or just too late? >
Process A recieves the signal and wakes up after process B has finished his job.
S.Heursch
- 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/
| |