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

[Dan Hecht <dhecht@vmware.com>]

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