Messages in this thread | | | Subject | Re: [patch 00/21] high resolution timers / dynamic ticks - V2 | From | john stultz <> | Date | Mon, 02 Oct 2006 12:23:25 -0700 |
| |
On Mon, 2006-10-02 at 15:08 -0400, Valdis.Kletnieks@vt.edu wrote: > 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..
This is what I suspect is the issue. Probably due to the new jiffies accounting being now time based, and one of the TSC unstable checks (the one you're tripping) being jiffies based. A tad bit circular :). I'm working w/ tglx to see what we can do here.
> > 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); > }
I'll also take a peek there and see if I cannot add an extra hook, so we don't have to rely on the jiffies stability check.
thanks -john
- 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/
| |