interrupt()
wake_up_interruptible()
schedule() returns
and which happens to be the core of one of the end-to-end latency tests
that our customers run on our product. Oh, and I'm currently running
2.2.5.
I started instrumenting things with rdtsc, measuring the delay between
when my interrupt handler started running and when schedule returns.
On a uniprocessor PIII it's about 1600 clocks, while on a dual PII
(BX motherboard) it's about 6700 clocks. For the record, the PII is
a 400MHz, 100MHz FSB, and the UP is a 500MHz.
Any help in trying to make this go faster would be appreciated. I
don't think I'm doing anything dumb - the interrupt handler does:
spinlock (uncontested)
one PCI read
few main memory reads/writes
wake_up_interuptible()
one PCI write (uncached)
spin unlock, return
The blocking thread does the proper add_wait_queue() / schedule_timeout()
thing, rather than disabling interrupts, and is already sleeping in
schedule_timeout() when the interrupt arrives. I'm timing from entering
the interrupt handler to the line after schedule_timeout() returns.
Is there anything I can do to speed things up? Am I getting nailed by
lack of processor interrupt affinity, or something like that? Are things
better in 2.2.13 or in newer 2.3 kernels?
Any help would be appreciated, as losing 10+ uS end-to-end latency is
really a drag...
-- ............................................................................ Peter Desnoyers 162 Pleasant St. (617) 661-1979 pjd@fred.cambridge.ma.us Cambridge, Mass. 02139 (978) 461-0402 (work) pjd@giga-net.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/