No, i meant what i said above. While returning from
sched_yield() the current SCHED_OTHER thread will be treated
just like if it had current->counter==0.
> 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.
You need it if a RT task might require another thread to make
some progress, otherwise you could deadlock.
[note that the schedule_others implementaion could be better,
but i wanted to have something that at least works, isn't
spread out all over the kernel sources, and is safe and easy
to update. I implemented it the way i did exactly because i
didn't want to make schedule() any more complex .]
> > 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?
it could be needed again, it's an inline so it does no harm.
> 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.
"decides switching to CPU 1 is too expensive" does not happen when CPU1
is idle. see wake_up_process()/reschedule_idle().
-
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/