On Mon, 21 Dec 1998, Linus Torvalds wrote:
>
>
> On Mon, 21 Dec 1998, Rik van Riel wrote:
> >
> > I have made what I believe to be a better, lower-overhead
> > reschedule_idle() and goodness() that should fix quite a
> > bit of the current SMP scheduling problems.
>
> Ok, with the cross-call your "goodness()" changes are a lot more
> acceptable. The thing is, that if you make goodness() quite that
> unwilling to run another CPU's process, then you do need to verify
> some way that the other CPU is willing to pick up the process in
> case it is important. Your previous patch didn't do that.
In RL, processes tend to spread out over the CPUs more slowly
than before -- and RT tasks that are waiting for eachother are
distributed a lot better too.
> I'll try this approach out on lmbench - I still worry about the
> cross-call overhead,
Don't try it yet -- it seems like I ran into a bug where
smp_send_reschedule() only sends reschedule signals to
CPU 0...
The bug is in arch/i386/kernel/smp.c::smp_message_pass(),
on line 1324:
{
dest=0;
target_map=(1<<target);
cpu_callin_map[0]=0;
}
This basically sets the destination for send_IPI() to
CPU 0, which results in excellent response times on
CPU 0 (and, fortunately, the tendancy for interactive
tasks to gather on CPU 0 so performance is still a bit
acceptable now :).
I guess 'dest = SET_APIC_DEST_FIELD(target)' would give
better results, but since I don't know the SMP code yet
I haven't tried it myself...
regards,
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]
