[ Re-sending in the hope that it will be archived ]
Ingo Molnar wrote:
> John Stultz wrote:
>
>> On Wed, 2007-01-24 at 10:41 +0100, John wrote:
>>
>>> I'm using the POSIX timers API. My platform is x86 running Linux
>>> 2.6.18.6 patched with the high-resolution timer subsystem.
>>>
>>> http://www.tglx.de/hrtimers.html
>>>
>>> My process is the only SCHED_FIFO process on the system. There are
>>> no user-space processes with a higher priority. AFAICT, only a
>>> kernel thread could keep the CPU away from my app.
>>>
>>> Is there a periodic kernel thread that runs every 2 seconds, cannot
>>> be preempted, and runs for over 50 ?s??
>>
>> This sounds like a BIOS SMI issue. Can you reproduce this behavior on
>> different hardware?
>
> note that only the -hrt patchset is used - not the full -rt patchset
> - so 50 usecs delays (and more) are quite possible and common.
Ingo,
You are correct, I only used -hrt.
I will _definitely_ give -rt a try.
I am fully aware that an occasional 100 ?s delay is possible, given a
soft real-time operating system. However, what I cannot explain is:
Why do these /occasional/ delays always happen a multiple of 2 seconds
apart? Can you explain this odd behavior?
> My question would be: does the same problem occur with the full -rt
> patchset and PREEMPT_RT? (see http://rt.wiki.kernel.org for details)
I will test on a different PC, as John suggested.
I will try the full -rt patchset in a few days.
+++++
On a related note, there is no -hrt patch for 2.6.19:
http://www.tglx.de/projects/hrtimers/
Is it because the patch for 2.6.19-rc4-mm1 applies cleanly to 2.6.19?
There is no -hrt patch for 2.6.20.
Has it been completely merged?
Regards.