Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

Dan Hecht
2007-03-07T21:46:30Z

On 03/07/2007 12:40 PM, Thomas Gleixner wrote:
> Real hardware copes well with relative deltas for the events, even when
> it is match register based. I thought long about the support for
> absolute expiry values in cycles and decided against them to avoid that
> math hackery, which you folks now demand.

First of all, I'm not "demanding" anything. I'm just trying to have a
technical discussion about the issues. If it comes out that absolute
expiry can't be done cleanly, and the cost out weighs the benefit, then
so be it. But, what's so wrong about having the discussion?

When you do have match register (or count and compare, whatever you want
to call it) based timers in real hardware, the relative expiry interface
in software is a bit suboptimal. You still have no idea how much time
has already gone by between the time you calculated the delta and when
you setup the hardware (you have a pretty good estimate, but can't know
for sure unless you disable caches and all other sources of
non-determinate latencies). So, you will always be a little late in
your timer firing. You may argue that no client of clockevents cares
about this little bit of lateness. But, it does exist, and can be
solved with a software interface that talks in terms of absolute expiries.

Perhaps we can't get around the 128-bit math problem, or maybe we can
think of a clever solution. If we can't, then maybe fixing the lateness
is not worth the cost 128-bit math. But, maybe there is a clean way
around the 128-bit math and we just need to approach it from another angle.

Dan