sched_clock -> check_tsc_unstable -> tsc_read_c3_time ?!?

[Lee Revell <rlrevell@joe-job.com>]

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
are:

     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?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/