Messages in this thread | | | From | Borislav Deianov <> | Date | Thu, 14 Oct 1999 00:45:55 +0200 | Subject | Re: [PATCH] scheduler cleanup |
| |
Artur,
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/
| |