Date: Wed, 13 Jun 2001 11:09:55 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: followup on 8 way SMP pani Message-ID: <Pine.BSF.4.21.0106131101280.40934-100000@beppo.feral.com> In-Reply-To: <XFMail.010613110037.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hang on a second. Clock interrupts are used for _two_ different things
> here, which is where you are getting confused I think. One is
> timekeeping, another is to handle things like per-process statclock, etc.
> All that per-process stuff we do on _all_ cpu's when we get a clock
> interrupt. Alpha is nice in that it broadcasts clock interrupts for this
> purpose. On x86, for example, we only have one clock interrupt and we
> have to IPI all the other CPU's to get this info.
But, in fact, in this case this is *not* a broadcast interrupt. Each TLSB CPU
board can have up to two CPUs. Each TLSB CPU board has an interval timer and a
Zilog duart. You use the TLINTRMASK{0,1} registers for each TLSB CPU board to
control whether one or both CPUs get DUART or Interval Timer or IPI (or any
other, for that matter) interrupt.
> Now, the second purpose is for timekeeping, and that is what hte i8254 is
> used for on SMP systems, because it is a timer that is system wide and not
> per-CPU. Does that make sense? What tlsb needs is a non-per-CPU,
> system-wide timer to be used for the timecounter stuff. That's all. No
> changes to any of the other clock code is needed.
And, to be safe, we should probably do the forward dance here as well- this
would guarantee that at least all CPUs notion of statclock is monotonically
delayed and ordered from the primary CPU. That is, it would be alway true
that:
CPU 0 - time tau
CPU 1 - time tau + epsilon1
CPU 2 - time tau + epsilon1 + epsilon2
...
I still have trouble believing that it won't screw things up to have different
(per cpu) time bases for statclock if you allow processes to move from one cpu
to the other. But I'll freely admit I'm an ignorant twit about the current
setup.
>
> In my first reply, (when you were going to disable clock interrupts on
> secondary cpu's) I was dealing with the first thing (per-process signals and
> stats) and noted that those should work fine as is. Doug then reminded me that
> I was a bit off track due to the way that nanotime, microtime, etc. all work.
>
> > I'm still trying to get it to work period for turbolaser. I think I tracked
> > down the panic and can move ahead I believe. This other issue has to really
> > be
> > slightly orthogonal.
>
> tlsb panics cause it has no timecounter on an SMP system. It needs a
> timecounter. That will fix the panic. So it's the same issue. :)
Well, I supposedly had *fixed* this lack of a timecounter issue some weeks
back (by hacking around it). I guess I need to look at this again.
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106131101280.40934-100000>