lkml.org 
[lkml]   [2005]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
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/

\
 
 \ /
  Last update: 2005-08-20 09:26    [W:0.113 / U:3.628 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site