Date: Wed, 13 Jun 2001 11:20:59 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Jacob <mjacob@feral.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: followup on 8 way SMP pani Message-ID: <XFMail.010613112059.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0106131101280.40934-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Jun-01 Matthew Jacob wrote:
>> 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.
Does each CPU get a clock interrupt at a specified hz? I.e., do all CPU's get
a X number of clock interrupts per second? That's all that statclock and
hardclock need. The relave timing of these interrupts isn't all that
important. Note that IPI's can suffer from delays as well, so we can't assume
anything about how soon (or not soon) that an IPI is delivered.
>> 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.
statclock doesn't care what time it is. It doesn't block, it runs with ints
disabled so the process doesn't migrate, etc. All statclock does is bump a few
stats. For hardclock all we do is possibly setup some pending signals. The
only thing that actually cares what time it is is the timecounter code. Now,
for clock interrupts, the timecounter is only updated on the boot CPU, so clock
interrupts are already safe and could use the pcc or what have you. The
problem is functions like nanotime(). (The non get* versions.) These
functions actually poke the hardware to get more precise timing since the last
timecounter update triggered by hardclock. Thus, if a secondary CPU tries to
do that (which is _not_ in a clock interrupt context, the problem is completely
unrelated to clock interrupts) then it needs to be able to get at the same
hardware timer that the boot CPU sees.
> 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.
No, this is only for SMP systems. We don't turn on the alpha timecounter on
systems with more than one CPU. UP systems and UP kernels should work fine.
> -matt
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.010613112059.jhb>