sched_clock -> check_tsc_unstable -> tsc_read_c3_time ?!?

From: Lee Revell
Date: Thu Oct 13 2005 - 15:01:56 EST

Looking at the latency traces it appears that sched_clock could be
optimized a bit:

evolutio-16296 0D.h4 32us : activate_task (try_to_wake_up)
evolutio-16296 0D.h4 33us : sched_clock (activate_task)
evolutio-16296 0D.h4 33us : check_tsc_unstable (sched_clock)
evolutio-16296 0D.h4 34us : tsc_read_c3_time (sched_clock)
evolutio-16296 0D.h4 35us : recalc_task_prio (activate_task)

check_tsc_unstable and tsc_read_c3_time appear to be new. Here they

49 /* Code to mark and check if the TSC is unstable
50 * due to cpufreq or due to unsynced TSCs
51 */
52 static int tsc_unstable;
53 int check_tsc_unstable(void)
54 {
55 return tsc_unstable;
56 }

73 u64 tsc_read_c3_time(void)
74 {
75 return tsc_c3_offset;
76 }

Shouldn't these be inlined or something? I know it's only a few
microseconds, but it seems like excessive function call overhead to me.
I don't use power management and the TSC is stable on this machine. Why
do we have to call these simple accessor functions over and over?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at