Re: [PATCH] scheduler cleanup

Artur Skawina (skawina@geocities.com)
Thu, 14 Oct 1999 21:10:41 +0100


[ There's no point in continuing the idle-cpus-wont-get-rescheduled
thread. What made me respond anyway is another issue Andrea now
mentioned; see below for details. I'll just say that the
write-one-function-at-a-time approach doesn't work. You do the whole
module and worry about external interfaces. Expecting to be able to
hack an internal function and not have to check, and if necessary
fix everything that depends on the old behaviour is silly. ]

Andrea Arcangeli wrote:
>
> Wrong. The other fix I mentioned is real but it applyes to CPUs that are
> running SCHED_OTHER tasks (but running SCHED_OTHER). The SCHED_OTHER tasks
> should be rescheduled immediatly, without my fix instead the scheduler may
> force a RT task to wait the SCHED_OTHER task to reschedule. Not a big
> issue but it _exists_.

the above does not make much sense (i think you meant RT tasks), but
i do see an issue with the stock reschedule_idle ("issue" because
i'm not yet convinced it makes much difference. Will think about this
more though.) [This is different from the previously mentioned
scenarios (no idle cpus involved).]
The scenario is: All cpus are busy and at least one of them is
running a "normal" thread; now a RT thread wakes up whose last cpu is
already running another RT thread -- the cpu executing the "normal"
thread is not guaranteed to be immediately rescheduled.
No, this does not appear to be a big issue. I'm not even convinced it
actually would make a noticable difference it RL. It's certainly
something to keep in mind when updating the scheduler related SMP
code. [i started doing this a while ago, but as it involved changes
across many architectures i've dropped that patch. I'll probably
do it in a few months, if nobody else beats me to it... ;)]

-
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/