Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Sep 2001 05:52:26 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        <Tor.Egge@fast.no>
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
Message-ID:  <20010901053233.W5355-100000@besplex.bde.org>
In-Reply-To: <200108311915.VAA34938@midten.fast.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Aug 2001 Tor.Egge@fast.no wrote:

> For RELENG_4, which uses Xintr0, this problem is reduced by adding the
> clkintr_pending variable (cf. revision 1.134 of clock.c and revision
> 1.38 of apic_vector.s)
>
> Looking more at the code, I now see that clkintr_pending is never set
> in -current due to Xintr0 not being used (Xfastintr0 is now used).
> Using a fast interrupt for the clock interrupt gives some of the same
> reduction of the race window size as the use of clkintr_pending.

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.

Making the clock interrupt handler fast doesn't significantly change
the problems as far as I can see.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010901053233.W5355-100000>