All of my experience is in producing production drivers for commercial
operating systems.
> If I take an interrupt and schedule a task, then
> the following
> sequence occurs
>
> irq
> copy data
> clear irq
> end of irq
>
> <-- Things pass -->
> at some point schedule task
> run stuff
>
Instead you should:
irq
poll device (assuming PCI or similiar)
if your device,
disable device irq (clears the IRQ) and
post to semaphore for deferred processing
end of irq
<-- Things pass -->
schedule processing that was waiting on semaphore
copy data
enable device interrupt
run stuff
go back to waiting for next IRQ, which may have already happened.
On an SMP machine with high activity, you could have the task (actually I
believe Linux would use task queues, but same difference) constantly running
on a CPU while new IRQs come in on the other processor. It can be better for
cache as well, since interrupts do less work and are therefore less
disruptive of the instruction and data cache. This would help cache on both
SMP and UP systems.
When you structure things this way, it also tends to minimize the amount of
driver code requiring that you disable interrupts. No data structures other
than the semaphore that are accessed from interrupt, so you don't have to
block interrupts when doing mutual exclusion.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/