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 (especially with the
IO_APIC moving interrupts around, the likelyhood of the wakeup event
happening on the same cpu that the sleeping processes was last on is
quite tiny) and blows a few cachelines needlessly across the bus on
each cpu in the idle loop etc.
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();
...
}
Later,
David S. Miller
[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
