From owner-freebsd-hackers Fri Aug 31 14: 4:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from midten.fast.no (midten.fast.no [213.188.8.11]) by hub.freebsd.org (Postfix) with ESMTP id 9D4E437B407; Fri, 31 Aug 2001 14:04:13 -0700 (PDT) Received: from fast.no (IDENT:tegge@midten.fast.no [213.188.8.11]) by midten.fast.no (8.9.3/8.9.3) with ESMTP id XAA38602; Fri, 31 Aug 2001 23:04:06 +0200 (CEST) Message-Id: <200108312104.XAA38602@midten.fast.no> To: bde@zeta.org.au Cc: jhb@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, Patrick.Guelat@imp.ch, phk@FreeBSD.ORG, drussell@saturn-tech.com, roberto@eurocontrol.fr, atrn@zeta.org.au, sthaug@nethelp.no, kpielorz@tdx.co.uk, bkarp@icsi.berkeley.edu, mb@imp.ch Subject: Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset From: Tor.Egge@fast.no In-Reply-To: Your message of "Sat, 1 Sep 2001 05:52:26 +1000 (EST)" References: <20010901053233.W5355-100000@besplex.bde.org> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 31 Aug 2001 23:04:06 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I remember this a bit better after reading my log message for rev.1.134 > of clock.c :-). > > At the time, the clock interrupt handler was not fast. However, it > could be delayed for a while by a fast interrupt handler (it still > can). Since it is delayed, it can't set clkintr_pending and we have > to rely on the irr overflow test working for longer. Rev.1.134 only > claims to work for the non-SMP case. The irr test apparently never > worked for SMP. Otherwise, it might be preferable to use the irr > overflow check instead of or as a backup to clkintr_pending, but it > can't be, since the irr bit is cleared when the irq is acked. This > behaviour also gives races for SMP: the irr bit may become invalid > while you're looking it when another CPU acks the irq. You need to check the irr and isr bit in the local apic on all CPUs after checking the delivery status bit in the IOAPIC. > Making the clock interrupt handler fast doesn't significantly change > the problems as far as I can see. Fast interrupts aren't blocked by Giant. As long as you need to hold clock_lock in order to set clkintr_pending without introducing time drift, you might as well step the clock while holding clock_lock. Deferring that work to clkintr() increases the latency from about 11 to 20 instructions before trying to obtain clock_lock. One way to solve this might be to always use the 8259 for i8254 interrupt delivery whenever possible and use (inb(IO_ICU1) & 1) in i8254_get_timecount when checking for a pending i8254 interrupt. The 8259 should not be programmed for auto-EOI since the EOI should be explicitly sent after setting clkintr_pending or stepping the clock. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message