Messages in this thread | | | Subject | Re: [patch 00/21] high resolution timers / dynamic ticks - V2 | From | Valdis.Kletnieks@vt ... | Date | Mon, 02 Oct 2006 15:08:19 -0400 |
| |
On Mon, 02 Oct 2006 11:38:36 PDT, john stultz said:
> Hmmm. So w/ -mm2 we're seeing the TSC get detected as running too slowly > (and its replaced w/ the ACPI PM), but for some reason that doesn't > happen w/ the dynticks patch.
It's been switching to ACPI PM for somewhere near forever, I never bothered to check into that because the PM timer provides a reasonably stable clock source (it drifts at about 24 ppm and NTP is happy with it, and I haven't gotten annoyed at the fact the PM timer is slow to read...)
I wonder if the TSC has been broken for forever on this box, and I'm just seeing it because dynticks doesn't fall over to PM timer..
> Now, how is cpuspeed changing the cpufreq? Is it using the /sys > interface? I've got hooks in so when the cpufreq changes we should mark > it unstable and fall back to ACPI PM, but maybe I missed whatever hook > cpuspeed is using.
Looking at the source, it appears to do this:
const char SYSFS_CURRENT_SPEED_FILE[] = "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_setspeed";
// set the current CPU speed void set_speed(unsigned value) { #ifdef DEBUG fprintf(stderr, "[cpu%u] Setting speed to: %uKHz\n", cpu, value); #endif write_line(CURRENT_SPEED_FILE, "%u\n", value); // give CPU / chipset voltage time to settle down usleep(10000); }
[unhandled content-type:application/pgp-signature] | |