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

[Thomas Gleixner]

On Wed, 2007-03-07 at 13:42 -0800, Dan Hecht wrote:
> 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.

With sane hardware yes. But there is no sane hardware. You need a (<=)
match machinery instead of the available (==) ones, which introduce
extra latencies and incorrectness. See arch/i386/kernel/hpet.c. We can
end up with returning -ETIME and an interrupt, as we have no control
over SMM code and such crap at all. For such devices the delta based
expiry is actually faster, as it avoids the calculation of wraps and the
possible 128 bit math in the reprogramming path.

This correctness discussion is purely hypothetical on current real world
hardware.

> 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.

Please put the clever solution inside of the clockevent. I can provide
the absolute time in nanoseconds without making you touch the
clockevent->next_event variable.

	tglx


-
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/