A few minor things:
On Wed, Oct 13, 1999 at 02:17:37AM +0100, Artur Skawina wrote:
> o sched_yield() works better for SCHED_OTHER threads, ie a process
> calling sched_yield() won't continue to run if there are other
> "normal" processes waiting for a CPU
I bet you don't mean that, it still depends on the dynamic
priority. Is there demand for a true "don't schedule me if there's
anybody else runnable at all"? It might be a little tricky to
implement with zero impact to the fast path.
> reverting back to LIFO would only be a matter of changing the
> "add_to_runqueue_last()" back to "add_to_runqueue()" in
> wake_up_process()]
With you patch add_to_runqueue becomes dead code, just remove it?
> + __set_current_state((state_value))
One set of brackets should be good enough here :)
On Wed, Oct 13, 1999 at 11:01:47AM +0200, Andrea Arcangeli wrote:
>
> You are avoiding _necessary_ yields. The other process may be blocked
> waiting for a reschedule from you. You can't assume that the other tasks
> have rescheduled the idle cpus. That may not happen to improve
> performances in some case.
I think I see what Andrea means here. Scenario: CPU 0 runs process A,
CPU 1 is idle, runqueue has only A. RT process B wakes up, previously
run on CPU 0 and decides switching to CPU 1 is too expensive. Process
A calls sched_yield(). You better reschedule.
We can maintain smp_num_idle_cpus but I doubt it's worth it just for
this particular check. Unless rc5des calls sched_yield ;)
Regards,
Borislav
-
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/