Date: Wed, 13 Jun 2001 10:48:33 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, wilko@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: followup on 8 way SMP pani Message-ID: <Pine.BSF.4.21.0106131042360.40934-100000@beppo.feral.com> In-Reply-To: <XFMail.010613103823.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. I think it's true that *system* time should only be adjusted by one CPU. But if you don't have a safe mechanism for getting nanotime offsets to system that is guaranteed to be monotonically increasing in hardware, you can always fall back to to the 'add one nanosecond under a lock' mechanism, right? 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. -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.0106131042360.40934-100000>