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