scheduling changes in pre-2.2.8-2

Andrea Arcangeli (andrea@e-mind.com)
Fri, 7 May 1999 03:05:56 +0200 (CEST)


Which is the sense of this?

/*
* Pass #1. (subtle. We might be in the middle of __switch_to, so
* to preserve scheduling atomicity we have to use cpu_curr)
*/
if ((p->processor == cpu) && related(cpu_curr(cpu), p))
return;

Why we do nothing if the preferred CPU is the current one?

And if the tasks are related it means that it won't be a big win to
reschedule the task in a _remote_ CPU, but it doesn't mean that we
shouldn't reschedule the current process on the _current_ CPU. Far better
to reschedule it on the _current_ CPU if they are related.

It would make far more sense to do a current->need_resched = 1 before
returning in such case according to me, but it would be wrong too because
we should do that only if the current task is going to expire it's
timeslice.

Comments?

Andrea Arcangeli

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