On Sun, 17 Jan 1999 21:31:12 +1100, Richard Gooch <rgooch@atnf.csiro.au> said:
> Hi, all. I just noticed that if I run a RT (SCHED_FIFO) process
> which hogs one CPU on a dual processor machine, system responsiveness
> becomes extremely poor. A second (SCHED_OTHER) process will happily
> compute away and get nearly 100% of the other CPU, but interactive
> processes (i.e. X, top, xterm and so on) can take several seconds
> before they respond to events. Even without the second SCHED_OTHER
> compute process, the interactive response is still dreadful.
It depends on which CPU the interrupt which wakes up the interactive
process comes in on. In kernel/sched.c, the wake_up_process() function
does try to schedule a newly woken process right now if it can, by
calling reschedule_idle(). That sends an inter-CPU reschedule command
to the target CPU to schedule the process.
What it will _not_ do is to preempt a process already running on that
other CPU. From reschedule_idle():
* [We can try to preempt low-priority processes on other CPUs in
* 2.3. Also we can try to use the avg_slice value to predict
* 'likely reschedule' events even on other CPUs.]
Ingo, any thoughts? Seems that if for any reason all wakeup interrupts
arrive at the same CPU which is running the SCHED_FIFO task, then we
will _never_ perform any successful wakeups without first exhausting the
other CPU's current timeslice.
--Stephen
-
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/