Kernel configuration problem? Waking up a thread from a hardware intterupt takes too long!

I am working on an embedded system that my company has developed. (My company also developed the driver.) The problem we're seeing is that on our embedded system it takes about 100 milliseconds (standard deviation of 0.5 milliseconds so this is very consistent) to wake up a thread that is waiting on a hardware interrupt.

However, running the same driver and executable (exact same binaries) on a desktop (with different kernel configuration) only takes about half a millisecond. We also ran tests on our embedded system with other operating systems (embedded XP and VxWorks) and the delays take no longer than 3 milliseconds, so we've been able to eliminate the hardware.

We have also changed part of the kernel configuration and recompiled the kernel. When we re-ran the tests with the new kernel, the delays doubled to about 200 milliseconds. So we believe the problem is the kernel configuration.

So my questions are: Has anyone had similar experiences? Does anyone have any suggestions for what kernel configuration(s) might be the culprit(s)?

Thank you for all your help!

- Kevin Hall

Reply to
Kevin Hall
Loading thread data ...

What exactly did you change?

Some random ideas:

- Does your hardware share its interrupt with another device?

- From what you wrote, it seems you are measuring the time between interrupt and *user thread* activation. If that is the case, then you may also want to measure the time between interrupt and *interrupt handler* invocation, so you can decide wether those 100ms delays are caused by the interrupt handling or by the user thread wakeup mechanism.

- How exactly does your user thread wait for the interrupt, i.e. are you using sleep_on()?

- What else is going on in your system (i.e. disk/network activity) while you run this test?

HTH

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

What is CONFIG_HZ on the two systems? (That setting was added in

formatting link
Newer systems use 1000, older systems used 100, I think. This might explain part of the problem?

- Dan

Reply to
Dan Kegel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.