PERFORCE change 99751 for review
Paolo Pisati
piso at FreeBSD.org
Wed Jun 21 12:41:49 UTC 2006
http://perforce.freebsd.org/chv.cgi?CH=99751
Change 99751 by piso at piso_newluxor on 2006/06/21 12:14:00
Updated a bit to reflect work status
Affected files ...
.. //depot/projects/soc2006/intr_filter/arm/arm/intr.c#2 edit
.. //depot/projects/soc2006/intr_filter/notes#2 edit
Differences ...
==== //depot/projects/soc2006/intr_filter/arm/arm/intr.c#2 (text+ko) ====
@@ -99,10 +99,9 @@
}
void
-arm_handler_execute(struct trapframe *frame, int irqnb)
+arm_handler_execute(struct trapframe *frame, int irqnb __unused)
{
struct intr_event *event;
- struct intr_handler *ih;
struct thread *td = curthread;
int i, thread;
@@ -115,14 +114,7 @@
continue;
/* Execute fast handlers. */
- thread = 0;
- TAILQ_FOREACH(ih, &event->ie_handlers, ih_next) {
- if (!(ih->ih_flags & IH_FAST))
- thread = 1;
- else
- ih->ih_handler(ih->ih_argument ?
- ih->ih_argument : frame);
- }
+ thread = intr_filter_loop(event, frame);
/* Schedule thread if needed. */
if (thread)
==== //depot/projects/soc2006/intr_filter/notes#2 (text+ko) ====
@@ -1,166 +1,7 @@
-This file serves as a sort of todo list for this branch as well as documenting
-what patches currently live in this branch.
-
-- Consolidate linux module version into MI location.
- - Not sure if we don't want flexibility of MD versions
-- Fixup asm constraints to use '+' rather than declaring a variable in both
- the input and output sections with '0', etc. in both the at386 and pc98
- bus headers. Also removes bogus 'cc' clobbers. gcc already clobbers 'cc'
- for inline asm stuff. For pc98 I tried to update the clobbers to be
- more realistic since they call functions. However, these clobber updates
- need to be verified against the actual pc98 code.
- - Moved to the jhb_ktrace branch for now. Also, haven't removed the
- "cc" clobbers yet.
-- Fixup atomic ops so that they treat the memory pointed to as an output and
- don't all clobber "memory", instead, just acquire variants clobber "memory".
- - alpha
- - amd64
- - why clobber memory in disable_intr()?
- - eventually we should not clobber all memory for bus_space, but just
- the memory we actually touch
- - arm
- - needs real acq variants to get "memory" clobber, then __swp() can stop
- clobbering "memory"
- - dev
- - drm clobbers memory for write barriers
- - drm and sym should use bus_space for barriers
- - gnu
- - contrib code
- - ia64
- - i386
- - why clobber memory in disable_intr()?
- - pc98
- - powerpc
- - not sure powerpc_mb() should clobber memory
- - sparc64
- - sys
-- Fixup td_ucred of thread doing execve() to re-sync with process ucred
- after single threading during an exec.
- - Untested
-- Use panic_thread pointer instead of panic_cpu to allow for migration
- of the panic'ing thread
- - Untested
-- Remove some bogus atomic_load_acq()'s and add ia32_pause()'s to
- stop_cpus() and restart_cpus().
- - Untested
-- Cleanup the SMP rendezvous code to properly use membar's to ensure function
- pointers are up to date before deferencing them.
- - Untested
-- Don't allow kthreads to get signalled and do bad things
- - Untested
-- Change amd64 to use [ls]fence instructions for memory barriers.
- - Untested (and no hardware, maybe peter can test)
-- Add a kproc API that does what kthread does right now
-- Add a real kthread API that creates just another thread inside of a kproc
- - Figure out what needs to be done to make a new kthread.. should each
- kproc have one ksegroup and one kse per cpu?
- - Do I just add the kse's when the first new thread is created?
- - Consolidate most of the kernel procs into a 'system' kernel proc that
- would be pid 0.
- - Stick all the 'idle threads' in a single 'idle' kernel proc.
-- kill taskqueue_swi in favor of taskqueue_thread since the only thing swi
- buys is being able to swi_sched() from a fast handler, but that doesn't
- make sense because you can't actually enqueue a task onto its queue from
- a fast interrupt context
-- Try to fix problems with stuck IPIs by raising TPR and enabling interrupts
- in spin loops. Need to perhaps generalize this so that critical sections
- do this. That really needs to only be done in spinlock_*() (and maybe some
- frobbing in intr_execute_handlers()) and needs to happen after the
- spinlock_*() changes happen.
-- KTR change: include __func__ along with __FILE__ and __LINE__ and display
- it after cpu number by default
-- Cheapen global stats counters via PCPU_LAZY_INC
- - cnt.v_intr
- - sparc64 is in asm, marius@ doing it
- - arm, powerpc?
- - fork counts?
-- Add a cache-line padded mtx_aligned union and use it for the mutex pools.
-- Add a per-thread counter of the number of sleep mutexes held (including
- recursion) and panic if we try to sleep with any held to provide a cheaper
- version of the current WITNESS check that doesn't bog the system down quite
- as bad.
-- Fix kernel linker locking
- + Convert mutex over to sx lock, needs to be held when calling the following
- functions
- - private:
- + linker_file_sys[un]init?
- + linker_file_[un]register_sysctls?
- + linker_file_register_modules?
- + linker_load_file?
- + linker_load_module_internal
- + linker_file_add_dependency (make private)
- - public:
- - linker_find_file_by_name? (make private?)
- - linker_find_file_by_id? (XXX: ndis)
- + linker_make_file
- + linker_file_unload_internal
- + linker_load_dependencies
- - ndis XXX
- - functions that grab the lock
- - private:
- - public:
- + linker_reference_module
- + linker_file_lookup_symbol
- + linker_load_module
- + linker_file_lookup_set
- + linker_file_unload
- - really remove Giant
-
-Active child branches:
-- jhb_intr - fast ithreads and MSI? (perhaps do MSI in jhb_acpipci)
-- jhb_ktrace - kernel debugging stuff, possibly per-thread ktrace
-- jhb_lock - rwlocks
-- jhb_needresched - scheduler fun
-- jhb_preemption - preemption
-- jhb_proc - proc locking, ABI stuff
-
-Space reserved for child branches:
-- Kill eintrcnt crap and make intrcnt/intrnames MI with a MD length
- constant. Export lengths instead.
- - Move non-stray intrcnt managing into intr_event code?
-- Use RCU to lock the per-source list of interrupt handlers.
-
-IRQ Shuffle:
-- Break up the icu_lock used to protect all IO APIC pins; possible solutions:
- - 1) use a hash table to assign each pin a spin lock
- - 2) give each CPU its own spin lock and when an pin is assigned a CPU,
- use that lock to protect that pin
- - 2a) bind the ithreads to the CPU that the IDT vector is assigned to
- and then you can just use critical sections to protect the APIC pins;
- actually, has to be spinlock_enter/exit rather than critical sections as
- we are protecting against bottom-half code rather than preemptions
-- atpic code is now only used for UP, so it can use spinlock sections
- explicitly rather than icu lock
-
-MSI Support:
-- i386
- - MSI interrupt source class
- - eoi just does lapic_eoi()
- - enable/disable source do little
- - need a function for allocating N vectors which creates the interrupt
- sources, allocs apic vectors for them, and then adds them
- - need a way to teardown as well, maybe nexus' bus_release_resource()
- would do that via a new release_resource intsrc method?
- - determine new-bus interface for MSI IRQs
- - need a way to request MSIs
- - pci bridge drivers (or bus) should have opportunity to blacklist
- known-bad bridges
- - need to support alloc'ing certain amounts (1, 4, 8, etc.) from the
- driver
- - i386 MSI class will add new interrupt sources after the I/O APIC IRQs
- - nexus (or somebody) will then create IRQ resources at rid 1 .. N and
- set them up for the child device
- - alternative is to fix MSI at rid 1 and let that resource have multiple
- IRQs. driver has to call bus_alloc_resourc() for each supported
- count, and bus_setup_intr() will have to grow an index. this
- interface requires the IRQs to be contiguously numbered though, and
- I think that is a bad assumption to enforce
- - child device can then do bus_alloc_resource() / bus_setup_intr()
-- amd64, just copy over from i386 for now
-
Remaining Interrupt Event issues:
+ 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
@@ -168,8 +9,8 @@
need a membar after the ie_thread write since we don't do any locking while
executing handlers.
-Interrupt filters (not sure if we want this?):
-- Second Pass: filters exist, but you only get one or the other; also, each
+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
interrupt storm detection stuff.
- Add a filter function pointer and prototype to intrhand
@@ -188,7 +29,9 @@
- Port to powerpc
- Port to arm
- This may or may not be commitworthy as a milestone at this point.
-- Third Pass: Change new-bus API to allow driver to have both filters and
+[DONE]
+
+- Second Pass: Change new-bus API to allow driver to have both filters and
threaded handlers.
- Determine new-bus API
- b/c both handlers need to be in the same intrhand, it is probably not
@@ -196,7 +39,8 @@
that bus_setup_intr() will grow a new filter pointer argument
- Fix bus_setup_intr() for all the archs
- This should be a commitworthy milestone of some sort
-- Fourth Pass: This requires some other support work to allow easy setup of
+
+- 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
a kernel scheduler rather than the UTS.
More information about the p4-projects
mailing list