[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200610021908.k92J8J8c012853@turing-police.cc.vt.edu>
Date: Mon, 02 Oct 2006 15:08:19 -0400
From: Valdis.Kletnieks@...edu
To: john stultz <johnstul@...ibm.com>
Cc: tglx@...utronix.de, Andrew Morton <akpm@...l.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Jim Gettys <jg@...top.org>,
David Woodhouse <dwmw2@...radead.org>,
Arjan van de Ven <arjan@...radead.org>,
Dave Jones <davej@...hat.com>
Subject: Re: [patch 00/21] high resolution timers / dynamic ticks - V2
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);
}
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists