Date: Sun, 10 Nov 1996 13:35:32 -0700 From: Steve Passe <smp@csn.net> To: Peter Wemm <peter@spinner.dialix.com> Cc: Bruce Evans <bde@zeta.org.au>, smp@freefall.freebsd.org, nate@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/isa syscons.c syscons.h Message-ID: <199611102035.NAA16738@clem.systemsix.com> In-Reply-To: Your message of "Mon, 11 Nov 1996 01:33:35 %2B0800." <199611101733.BAA15722@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> Bruce Evans wrote:
> > I'm going to replace the i586 optimized copying options (including the
> > one for copyin/copyout that went away) by negative-logic npx flags.
> > This is mainly for 2.2. I don't trust copying through the FPU to work
> > on i586 clones.
>
> We currently have to #ifdef out the i586_bcopy on the SMP code which does
> not yet understand the fact that there is more than one FPU involved...
> (duh!) This probably explains why floating point is *extremely*
> unreliable..
>
> Just the same as we have to #ifdef out the pentium_microtime stuff,
> although I must take a closer look again now that you fixed the problem of
> masked-for-too-long clock interrupts.. There was some discussion a
> while ago about having the 100Hz timer interleaved across all cpus in a
> round-robin fashion, and if each cpu kept per-cpu smoothing/rate/etc
> variables, it might just be able to cope with it with enough tweaks.
this is currently available in SMP by using the APIC_IO option in the
kernel config file AND NOT defining "TEST_LOPRIO" in i386/include/smptests.h.
TEST_LOPRIO causes all INTs to be offered to all available CPUs via the
"lowest priority" algorithm of the APICs. Without TEST_LOPRIO defined
only the system clock INT is sent to all CPUs (assumming options APIC_IO
is set). I guess this means that it is unpredictable as to which CPU gets
the clock tick. We could do a psuedo round robin scheme by explicily
reprogramming the target for that INT each tick, but the "masked-for-too-long
clock interrupts" would still be a problem.
This is out of my area of knowledge, but would it make sense to localize the
tick service to one CPU, but make it aware that it needs to broadcast a
"tick" IPI ("all but self" InterProcess Interrupt) to the APIC bus for
puposes of context switch on the other CPUs?
If the "per-cpu smoothing/rate/etc" is do-able it would be better in the sense
that there would be less problem with INTerrupt latency. Still, we
would need the "tick IPI" to guarantee good accuracy for the context switches
on the other CPUs. And then there was talk of "per-process-variable time
quantums"...
--
Steve Passe | powered by
smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611102035.NAA16738>