cvs commit: src/sys/amd64/amd64 intr_machdep.c io_apic.c local_apic.c mp_machdep.c src/sys/amd64/include apicvar.h intr_machdep.h src/sys/amd64/isa atpic.c src/sys/i386/i386 intr_machdep.c io_apic.c local_apic.c mp_machdep.c ...

[Andrew Gallatin]

Scott Long writes:
 > Andrew Gallatin wrote:
 > 
 > > Scott Long [scottl at samsco.org] wrote:
 > > <...>
 > > 
 > >>  Also, it's not so
 > >>much important which CPU gets the interrupt as it is which CPU runs the
 > >>ithread for that interrupt.  I guess that you can get a little better
 > >>latency by preempting directly from the low-level interrupt handler into
 > >>the ithread, but I don't know if that is noticable noise above the cost
 > >>of the context switch and inevitable lock operations and contention
 > >>involved.
 > > 
 > > 
 > > What do you mean by "preempting directly from the low-level interrupt
 > > handler into the ithread" ?  Do you mean running the ithread directly
 > > in the context of the hardware interrupt until it does something where
 > > it needed to block?  Do we do this now?
 > > 
 > > Thanks,
 > > 
 > > Drew
 > > 
 > > 
 > 
 > No, I just mean that the CPU running the low-level handler is likely
 > to schedule and run the ithread as soon as the interrupt exits,
 > preempting whatever thread happened to be running before the interrupt
 > occurred.  This isn't context stealing, it's just preferential
 > scheduling.  You still need to wind through the scheduler and do a
 > context switch to get there.

Oh, darn.  Nevermind :)

Drew