On 03/07/2007 12:15 AM, Ingo Molnar wrote: > On the other hand, Linux's internal details, semantics, approaches are a > lot more ad-hoc and alot more affected by changes in the hardware > environment - that's why i'd not like to see some external ABI > constraint limit aspects of those internals. > > For example, VMI_CALL_SetAlarm takes a 'cycles' argument. Cycles is a > quite bad unit for an API, it should be absolute time, nanosec or > picosec based instead. We could easily see CPUs that have /no concept of > cycles/, at all! Even today's CPUs have hardly any fix concept of > cycles, due to cpufreq. It's as if 15 years ago we had based sys_mmap() > around the concept of '16-bit segments'. We could certainly make it work > on current hardware but it would look pretty awkward today. > > Ingo, In the VMI definition, "cycles" does not mean "cpu cycles". It is used in the normal way to mean "an interval of time during which a sequence of a recurring succession of events or phenomena is completed" [Merriam-Webster]. In this case, the recurring event is the increment of a counter. The routine VMI_CALL_GetCycleFrequency defines how many of these events occur per second. The rate is not variable, so is not subject to cpu phenomena such as cpufreq. And it does not need to be tied in any way to cpu cycle frequency. How your cpu is implemented is not relevant. If a hypervisor wishes to expose it's time counters in units of nanoseconds, then it simply returns 1000000000 from GetCycleFrequency. Dan _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
