Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2008 13:18:44 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Julian Elischer <julian@elischer.org>
Cc:        Peter Wemm <peter@wemm.org>, David Xu <davidxu@freebsd.org>, arch@freebsd.org
Subject:   Re: amd64 cpu_switch in C.
Message-ID:  <20080314115225.G34431@delplex.bde.org>
In-Reply-To: <47D9BDF3.80409@elischer.org>
References:  <20080310161115.X1091@desktop> <47D758AC.2020605@freebsd.org> <e7db6d980803120125y41926333hb2724ecd07c0ac92@mail.gmail.com> <20080313124213.J31200@delplex.bde.org> <20080312211834.T1091@desktop> <20080313230809.W32527@delplex.bde.org> <20080313132152.Y1091@desktop> <47D9BDF3.80409@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Mar 2008, Julian Elischer wrote:

> Jeff Roberson wrote:
>> I'm not sure why you feel masking interrupts in spinlocks is bogus.  It's 
>> central to our SMP strategy.  Unless you think we should do it lazily like 
>> we do with critical_*.  I know jhb had that working at one point but it was 
>> abandoned.

Masking interrupts in spinlocks breaks fast interrupts among other things.

Yes, I think it should be done like in critical_*.  My version has
done this for 6 years or so, but I don't really care about SMP and
never made it work right for SMP.  Its main impact is on fast interrupt
handlers.  Interrupt handlers cannot access any data that is not locked,
and for non-broken fast interrupt handlers, in practice this means not
accessing any global data, since locking global data would be too hard
and/or slow.  Global data includes all per-CPU-data, and I enforce
non-access to this by loading %fs with 0 in fast interrupt handlers.
This makes fast interrupt handlers quite difficult to write.  An
interrupt handler like hardclock(), which stomps around in global data,
in some places without even locking the data, is far too large and
complicated to be a non-broken fast interrupt handler.  I use normal
interrupt handlers for hardclock() and statclock() so my lower interrupt
latency costs performance.

> My memory is that we used to mask interrupts lazily in 4.x

Right.  Only for i386.  The masking is in the PIC so it only affects
devices on non-fast interrupts, which should only be slow devices.
Lazy masking for critical_*() has the same results (it only affects
non-fast interrupts) although its mechanism is different.

I implemented this in 386BSD and am unhappy that it was broken in
SMPng, though with CPUs hundreds of times faster than they were when
386BSD was new, and with devices not so much faster and/or with larger
buffers, the extra latency rarely matters in practice; also, with SMP
there is only extra latency if all CPUs happen to hold a spinlock at
the same time.

Bruce



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