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

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