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:
> 
> 
>>>how about the patch below? One of the important benefits of the 
>>>threaded timer IRQ is the ability to make xtime_lock a mutex.
>>
>>The problem is that that removes the
>>	cur_timer->mark_offset();
>>	do_timer(regs);
>>in time. [...]
> 
> 
> i'm not sure i understand what you mean. My change does:
> 
> | @@ -294,6 +313,7 @@ irqreturn_t timer_interrupt(int irq, voi
> |         write_seqlock(&xtime_lock);
> |
> |         cur_timer->mark_offset();
> | +       do_timer(regs);
> |
> |         do_timer_interrupt(irq, NULL, regs);
> 
> 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.  We then want to have that marked (mark_offset) with a TCS (or other 
clock) so we can tell how many nanoseconds past that time any given point of 
time is.  This is used by gettimeofday.  So if we wait till the thread gets 
control, we have a lot of variability in when, exactly, the event took place. 
We already have interrupt latency in the mix, but, by moving it to a thread, we 
also add scheduling delays due to other RT threads (the actual intent of making 
it a thread, right).

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.  The 
changes I am suggesting are aimed at getting a good a handle on the current time 
as possible.  They say nothing about how accurate we are in expiring a timer, 
for example.
> 
> 	Ingo
> 

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