PERFORCE change 101856 for review
Paolo Pisati
piso at FreeBSD.org
Tue Jul 18 16:05:54 UTC 2006
http://perforce.freebsd.org/chv.cgi?CH=101856
Change 101856 by piso at piso_newluxor on 2006/07/18 16:05:18
Updated again.
Affected files ...
.. //depot/projects/soc2006/intr_filter/notes#6 edit
Differences ...
==== //depot/projects/soc2006/intr_filter/notes#6 (text+ko) ====
@@ -2,13 +2,27 @@
+ Port to powerpc
- has a few XXX, doesn't handle multiple fast
[DONE]
+
+ Port to arm
- I think the IRQ needs to be unmasked when a handler is added
-- Fix a race in intr_event_add_handler(). We should create the ithread if
+
++ Fix a race in intr_event_add_handler(). We should create the ithread if
needed and set ie_thread before adding the handler to the TAILQ. We would
need a membar after the ie_thread write since we don't do any locking while
executing handlers.
++ All the archs (except for i386 & amd64) didn't have their interrupt
+ EOIing and masking MD code reviewed
+
++ Fix interrut storm logic: what if an interrupt source storms
+ and we have only filters on that line? Moreover, the interrupt
+ storm handling code now work only when an ithread is scheduled...
+
++ Bfe was converted to be a filter+ithread driver, but there're
+ races when accessing bfe_istat, and perhaps other races while
+ accessing the hw registers. The simplest solution would employ
+ a spin lock, but i'm wondering about the performance penalty...
+
Interrupt filters:
- First Pass: filters exist, but you only get one or the other; also, each
threaded handler has its own ithread. Also, this will probably break the
@@ -41,12 +55,13 @@
- Fix bus_setup_intr() for all the archs
- This should be a commitworthy milestone of some sort
[DONE]
-XXX: all the archs (except for i386 & amd64) didn't have their interrupt
-EOIing and masking MD code reviewed
- Convert a driver to use filter+ithread
[DONE]
+- Benchmark the different interrupt models:
+ pre SMPng (4.x), polling(???), ithread only and filter+ithread.
+
- Third Pass: This requires some other support work to allow easy setup of
kernel threads (not just kernel processes) as well as letting kernel
processes have KSE's that do continuations that do a kind of upcall into
@@ -55,3 +70,4 @@
- embed a struct task in each intrhand and use a single intr kernel process
with one kse per CPU and threads that spawn new threads when blocking
to execute tasks from a interrupt taskqueue
+
More information about the p4-projects
mailing list