On Fri, 18 Dec 1998, David S. Miller wrote:
> Date: Fri, 18 Dec 1998 13:36:40 +0100 (CET)
> From: Rik van Riel <[EMAIL PROTECTED]>
>
> If we want to do something useful with PROC_CHANGE_PENALTY we
> should start by trying to reschedule the app on it's previous CPU
> and not on the (random) current->cpu...
>
> And most of the time on x86 it happens because idlers on SMP there
> just slam into the scheduler() over and over even when zero useful
> work is available. This encourages cpu changing and blows a few
> cachelines needlessly across the bus on each cpu in the idle loop
> etc.
This is a Big Evil(tm) indeed...
The second Big Evil is reschedule_idle(), which always tries
to reschedule the 'new' process on the current CPU. I will
change this either ASAP or just rather quickly :)
> I know some people might be getting sick of seeing this Sparc64
> example, but this is how I deal with this behavior on SMP systems
> there, and yes it makes a huge difference and the system feels much
> smoother, even a 14 cpu system feels reasonable...
>
> cpu_idle() {
> ...
> if (current->need_resched != 0 ||
> ((p = init_task.next_run) != NULL &&
> (p->processor == smp_processor_id() ||
> (p->tss.flags & SPARC_FLAG_NEWCHILD) != 0)))
> schedule();
> ...
> }
Anyone against using this code for other architectures
as well?
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. [EMAIL PROTECTED] |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
