I've got some context questions. I'm on intel, measuring elapsed time using the tsc for various parts of my code running in a real-time thread.
I do have various interrupts enabled, both my 'real-time interrupt', and various interrupts that are being handled via drivers in the linux kernel. And I'm observing fairly infrequent 'hiccups' in the elasped time that can't really be explained as cacheline misses, bad branch prediction, or the like. I know it's not my 'real-time' ISR, because I'm tracking that internally. So my question boils down to this: When a non-real time interrupt hits while a real-time thread is running, how much of the normal linux driver is able to preempt the real time thread? I am assuming that bh's and/or tasklets that might be kicked off as a result of interrupt activity would never run until the normal linux kernel context is restored. But what about the actual linux ISR (from the linux point of view - not the actual hardware ISR)? Is this held off too until linux context is restored, and then invoked via a simulated interrupt, or is the linux ISR actually allowed to run 'under' a real-time thread? Suppose I'm in the linux level ISR code, and an interrupt hits that I've got a real-time handler for - the linux ISR is immediately preempted, right? Just wondering, as answers will help me better understand the timing I'm seeing for my real-time threads. TIA, -Dave i. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
