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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
