Re: [patch 00/21] high resolution timers / dynamic ticks - V2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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);
}

Attachment: pgpvEwzMcvQRQ.pgp
Description: PGP signature

[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]
  Powered by Linux