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

From: George Anzinger
Date: Sat Aug 20 2005 - 02:22:06 EST


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@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/