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 ...

[Scott Long]

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.

Scott