Are you seeing that happen? If so, you shouldn't. It won't happen on
ppc/mips/alpha. We take into account the Linux task when setting the next
tick. If we can give Linux its tick on-time without affecting RT tasks we
do.
In your example what should happens is linux gets its tick at 10ms from
now, the RT task gets its tick 20ms from now and Linux gets its tick after
the RT task has finished running.
} I looked. You patch do_gettimeoffset at runtime. So anybody who accesses the Linux
} timer via this interface will see the timer monotonically increasing. Ok.
}
} But I don't think it answers my question.
}
} For example, assume the linux timer interrupt fires 100 times a second (every
} 10msec). An RT task programs the one-shot timer to go off in 20 msec. The timer
} interrupt fires at the programmed time. The RT interrupt handler calls the kernel
} timer interrupt handler 10 msec later than normal. Normally, the linux timer
} interrupt updates the jiffie count (among other things). So we effectively lose a
} jiffie increment. I'm not sure what other side effects might occur.
}
} Is this untrue or does it just not matter?
-- [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/rtlinux/