Re: [PATCH 2.6.13-rc6-rt9] PI aware dynamic priority adjustment

[George Anzinger <george@mvista.com>]

Thomas Gleixner wrote:
> George,
>
> On Fri, 2005-08-19 at 17:19 -0700, George Anzinger wrote:
>
> > > 2. Drift of cyclic timers (armed by set_timer()):
> > >
> > > Due to rounding errors and the drift adjustment code, the fixed
> > > increment which is precalculated when the timer is set up and added on
> > > rearm, I see creeping deviation from the timeline. 
> > >
> > > I have a patch lined up to base the rearm on human (nsac) units, so this
> > > effect will go away. But this is waste of time until (1.) is not solved.
> > >
> > > George ???
> >
> > Could I (we) see what you have in mind?
>
>
> Nothing which applies clean at the moment and I have no access to the
> box where the patch floats around.
>
> It's simply explained.
>
> Current code:
>
> set_timer()
> 	calc interval->jiffies / interval->arch_cycles;
> 	based on it.interval
>
> rearm()
> 	timer->expires += interval->jiffies;
> 	timer->arch_cycle_expires += interval->arch_cycles;
> 	normalize(timer);
>
> Patched code:
>
> set_timer()
> 	timer.interval = it.interval; 
> 	timer.next_expire = it.value; 
> 	both stored as timespec
>
> rearm()
> 	next_expire += interval;
> 	calc timer->expires/arch_cycle_expires;
> 	
> So on each rearm we eliminate the rounding errors and take the drift
> adjustment into account.
>
> It adds some calculation overhead to each rearm, but ....
I think the standard was written to eliminate the need for this.  The 
notion is that we have a resolution which we use in the calculations so 
while there may be drift WRT his request, there should be no drift WRT 
the requested value rounded up to the next resolution.

Still, if we can't keep that resolution in arch_cycles...

On another issue along this line, I have been thinking of changing the 
x86 TSC arch cycle size to 1ns.  (NOT the resolution, the units for the 
arch cycle.)  The reason to do this is to correctly track changes in cpu 
frequency as it is today, we would need to track down and update all 
pending HR timers when ever the frequency changed.  By using a common 
unit all we need to do is change the conversion constants (well I guess 
they would not be constants any more :).  I REALLY don't want to do this 
as it does add conversion overhead, but I can not think of another clean 
way to track TSC frequency changes.

--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/