Re: [PATCH] to fix xtime lock for in the RT kernel patch

[George Anzinger <george@mvista.com>]

Ingo Molnar wrote:
> * George Anzinger <george@mvista.com> wrote:
> 
> 
>>>so ->mark_offset and do_timer() go together, and happen under
>>>xtime_lock. What problem is there if we do this?
>>
>>We are trying to get an accurate picture of when, exactly in time,
>>jiffies changes. [...]
> 
> 
> but that's the point of allowing the threading of the timer interrupt. 
> If you _have_ an interrupt source (and task) that _is_ more important
> than the timer interrupt then so be it. Yes, the accuracy of timekeeping
> may suffer.
> 
> so everything is relative, and the user decides which functionality
> should have the better latency. do_offset() can take up to 10 usecs so
> it's a latency source i'd like to keep out of the direct IRQ path, as
> much as possible.

What I am suggesting is spliting the mark code so that it would only grap the 
offset (current TSC in most systems) during interrupt processing.  Applying this 
would be done later in the thread.  Since it is not applying the offset, the 
xtime_lock would not need to be taken.
> 
> 
>>We can handle (do today) some variability in this area, but, at least
>>for RT systems, we would like to get this down to a small a window as
>>possible. 
> 
> 
> by default the timer interrupt has the highest priority, and you can
> still change it to prio 99 to avoid any potential impact from RT tasks
> or other interrupt threads.
> 
> 	Ingo
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/