Date: Tue, 18 Jul 2006 16:05:50 GMT From: Paolo Pisati <piso@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 101856 for review Message-ID: <200607181605.k6IG5o8Y071642@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=101856 Change 101856 by piso@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 +
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607181605.k6IG5o8Y071642>