Date: Thu, 14 Dec 2000 14:45:51 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, John Baldwin <jhb@FreeBSD.ORG>, alpha@FreeBSD.ORG Subject: RE: mutex/ithread jitters? Message-ID: <Pine.LNX.4.21.0012141440090.28426-100000@zeppo.feral.com> In-Reply-To: <Pine.LNX.4.10.10012142207190.1637-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> My understanding is that Alpha is actually IPL based and masking using
> actual level will kill most advantages if threading interrupts, at least
> for level sensitive. My probably false understanding let me think that
> result will be increase of interrupt latency without any gain in anything
> by threading interrupt handlers.
>
> On IA32, we can mask at IO APIC level and EOI in advance, but this looks
> like odd tinking to me and may-be will just fight with IO APIC
> optimizations that assume some behaviour of the CPU in optimization
> heuristics. Anyway tampering the IO APIC may well be slow. (?)
The problem, in sum, is that the FreeBSD ithread architecture assumes you can
quiesce level sensitive ints (without getting to the the driver for that
h/w) so that you can continue to run and schedule ithreads until you get to
the driver that will deal with the interrupt for that interrupting device.
The problem here is that it's not always clear that you can safely quiesce
interrupts this way. It's fairly clear with an IO-APIC. It's been a bit of an
edge case in how we deal with the Alpha. One *should* be able to do so, but
we've been having problems with it.
>
> Always regarding level-sensitive interrupts, I happen to dream of
> implementing interrupt handling in 2 separates handlers.
>
> - A fast half handler that runs in the "expected by hardware" interrupt
> context and that gets device status information, clears the device
> interrupt condition, passes the info to he other half handler.
>
> - the other handler may be ithread if it is not fast enough or may
> contend too much on other resources.
>
> (This is not original, indeed :-) )
>
> I read Solaris does thread interrupt handlers. Could it be that Sparc
> hardware has been specifically tailored for this not to have adverse
> effects ?
No. They also run the threads at h/w interrupt priority. First of all, you
can't do any kind of non-spin locking (or much of *anything*) above IPL 10-
the clock and the uarts and audio actually come in above IPL 10 (that's why
the zs && audioamd drivers are multi-level interrupt drivers). Secondly, there
are explicit warnings about attempting do some things in interrupt context.
That is, you *can* do things like cv_wait, but you get warnings in section 9
man pages, e.g. (from condvar(9f)):
If cv_wait(), cv_timedwait(), cv_wait_sig(), or
cv_timedwait_sig() are used from interrupt context, lower-
priority interrupts will not be serviced during the wait.
This means that if the thread that will eventually perform
the wakeup becomes blocked on anything that requires the
lower-priority interrupt, the system will hang.
For example, the thread that will perform the wakeup may
need to first allocate memory. This memory allocation may
require waiting for paging I/O to complete, which may
require a lower-priority disk or network interrupt to be
serviced. In general, situations like this are hard to
predict, so it is advisable to avoid waiting on condition
variables or semaphores in an interrupt context.
-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.LNX.4.21.0012141440090.28426-100000>