Hi,
my latest scheduler patch gave poor performance in some
cases (when the task is on the 'wrong' CPU) and I seem
to have tracked it down to smp_message_pass() in
arch/i386/kernel/smp.c...
The goal of the function is to pass a message to another CPU
to tell it to do something (reschedule, in this case). The
problem is that the message doesn't seem to arrive for a
while, or the schedule just doesn't occur for some strange
reason...
I found this (rather suspect looking) piece of code in smp.c:
/*
* Set the target requirement
*/
if (target==MSG_ALL_BUT_SELF)
{
dest=APIC_DEST_ALLBUT;
target_map=cpu_present_map;
cpu_callin_map[0]=(1<<p);
}
else if (target==MSG_ALL)
{
dest=APIC_DEST_ALLINC;
target_map=cpu_present_map;
cpu_callin_map[0]=0;
}
else
{
dest=0;
target_map=(1<<target);
cpu_callin_map[0]=0;
}
It seems to imply that we set the target to 0 if there's no
magic value to use. This corresponds with my experience that
the system feels responsive when my processes are on CPU 0
and performance sucks when the stuff is on CPU 1 (xosview
tells this to me).
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]
