Messages in this thread | | | Date | Tue, 19 Jan 1999 18:20:14 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: Scheduler problems |
| |
Hi,
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/
| |