Andi Kleen wrote:
.write_msr = native_write_msr,
.read_tsc = native_read_tsc,
.read_pmc = native_read_pmc,
+ .get_scheduled_cycles = native_read_tsc,
+ .get_cpu_khz = native_calculate_cpu_khz,
.load_tr_desc = native_load_tr_desc,
Description missing?
I missed a title / signed-off on this guy.
Internally, sched_clock runs in units of nanoseconds, not CPU cycles.
This was wrong in my previous patch. Fix it so everyone can use the
same cycles_2_ns code in tsc.c.
Signed-off-by: Zachary Amsden <[email protected]>
Please write at least two paragraphs or more on each new hook
you want to add.
Not a new hook; I just changed the name.
My feeling is that rdtsc should work fine here. If not please explain.
It depends. Scheduled clock must be in units of available time - stolen
time is not always evenly distributed. If you make rdtsc just be
scheduled clock, that almost works. But most places that use rdtsc
expect it to be in cycles of approximate real time, and to leap forward
if something like SMM comes along and steals time.
Not that this is pretty. Arguably, the TSC should just run at a fixed
rate, not progress during stolen time. This idealized TSC assumption is
not however how Linux is making use of the TSC today. TSC is more like
real time, only in a VM, it can't quite keep up with real time, so it
gets simulated.
Scheduled (or available) time and real time are good notions. Stolen
time is debatable. But TSC is basically just always wrong. That's why
I don't want to overload the rdtsc operation.
Zach
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
