Well, Victor pretty much spelled it out right: Linux doesn't give you any scheduling guarantees. It was designed to be a "best case" OS and does a pretty good job at it too. For real-time, however, there are a couple of areas in the kernel that don't help. The main one I can think of is the VM subsystem.
When you do a system call to the kernel services, the sequence of events is usually the following: 1) Entry in system call code in the kernel 2) Test to see if ptrace() has to be called 3) Call the actual system call 4) Call on the scheduler if needed 5) Return to the caller When an interrupt occurs, the sequence of events is usually the following: 1) Entry in the interrupt handling code in the kernel 2) Call to interrupt handler 3) Call on the scheduler if needed 4) Return from exception (there used to be another step between 2 and 3 where the code would test if a softirq, bottom half, needed to run and would then call the do_softirq function, but this isn't how it is done in more recent kernels). This is a simplification and others have documented this sequence further. Try the "understanding the Linux kernel" by O'Reilly for an in-depth description. The explanation, however, still assumes that do_bottom_half is part of the sequence of calls. Both in the case of system calls and in the case of interrupts and exception, anything can happend during the call to the system call code or interrupt/exception handler, including non-deterministic behavior. With the O(1) scheduler in the kernel, the scheduler's behavior becomes deterministic, but you still have no control over softirqs and, most importatnly, the actual system call. If you want to know precisely what the kernel is doing with your code, you may want to try out the Linux Trace Toolkit (http://www.opersys.com/LTT). It will tell you exactly what the kernel does and why your app doesn't get control back as you expect it. Best regards, Karim Cassia Yuri Tatibana wrote: > But sometimes, like coming from nowhere, one instance of the > experiment returns a time value much higher than the rest. > (ex: when most of the values are 67us, this particular instance returns > 20ms). And I just can't imagine what it could be!! All I know is that it > is caused by the nanosleep call, which, despite being called with a time > parameter very close to the rest of the instances, takes much more time in > sleep.. =================================================== Karim Yaghmour [EMAIL PROTECTED] Embedded and Real-Time Linux Expert =================================================== -- [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/
