Date: Wed, 13 Jun 2001 11:00:37 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-alpha@FreeBSD.org, wilko@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: followup on 8 way SMP pani Message-ID: <XFMail.010613110037.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0106131042360.40934-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Jun-01 Matthew Jacob wrote: >> >> > It was my belief/speculation that we ran into problems because all CPUs >> > were >> > getting a clock interrupt. Maybe that's not right? >> >> No. We only adjust the timecounters on the primary CPU's clock interrupt, >> so >> that isn't a problem. The problem that Doug pointed out with nanotime(9) is >> that if two different CPU's try to read the time at the same time, they need >> to >> get the same value. This is not guaranteed if we use the pcc. This can >> become >> more problematic if a process migrates from one CPU to another and as a >> result >> time "goes backwards" per se. What we need is a global timer. On an SMP >> system, we can't use the CPU cycle counter for this. > > Well, right. There are a number of possible sources for this on each > platform. > But it can't possibly be correct to assume that N different interval timer > interrupts are anywhere within an aeon of each other. I can't believe that > allowing clock interrupts on all cpus can be considered correct. Even if > there > is only one interrupt source (i.e., one hirez clock) there are quantization > errors that would always make time different if maintained differently in > each > CPU. 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. 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. 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. :) -- 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.010613110037.jhb>