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

2005-01-27 Thread Ingo Molnar
* George Anzinger wrote: > Ingo, I have been looking at the code being proposed by John Stultz. > It looks like it handles all the issues I am talking about here. I > think it would be best to leave the RT patch as it is WRT this issue > and work on getting John's patch ready for prime time as

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

2005-01-27 Thread George Anzinger
George Anzinger wrote: Ingo Molnar wrote: * George Anzinger wrote: 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

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

2005-01-21 Thread George Anzinger
Ingo Molnar wrote: * George Anzinger wrote: 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

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

2005-01-21 Thread Ingo Molnar
* George Anzinger wrote: > 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 t

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

2005-01-21 Thread George Anzinger
Ingo Molnar wrote: * George Anzinger 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 t

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

2005-01-21 Thread Ingo Molnar
* George Anzinger 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

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

2005-01-21 Thread George Anzinger
Ingo Molnar wrote: * George Anzinger 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

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

2005-01-21 Thread Ingo Molnar
* George Anzinger 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 und

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

2005-01-21 Thread George Anzinger
Ingo Molnar wrote: * George Anzinger wrote: It seems to me that we need to either do the attached or to rewrite the timer front end code to just gather the offset info and defer to the timer irq thread to update jiffies and the offset stuff. In either case we really can not split the two and we

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

2005-01-20 Thread Ingo Molnar
* George Anzinger wrote: > It seems to me that we need to either do the attached or to rewrite > the timer front end code to just gather the offset info and defer to > the timer irq thread to update jiffies and the offset stuff. In > either case we really can not split the two and we do need th

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

2005-01-20 Thread George Anzinger
It seems to me that we need to either do the attached or to rewrite the timer front end code to just gather the offset info and defer to the timer irq thread to update jiffies and the offset stuff. In either case we really can not split the two and we do need the xtime_lock protection. -- Georg