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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
