Slashdot Mirror
Will 'PowerNow' Cause Trouble in Linux?
Vandermar asks: "AMD's 'PowerNow' promises to vary clock speed in 50mhz increments on the fly similar to Crusoe. If I remember correctly, Linus had to make changes to the Linux kernel to keep it from freaking out when the clock speed changed. Will the variable clock speed of AMD's new mobile chips require changes to the kernel (or will PowerNow need to be disabled)? How was the kernel modified to allow it to run on Transmeta chips?"
I don't know about the Transmeta CPUs, but it seems that AMD's embedded processors do play nice with Linux.
Details are on the AMD site.
There's currently code in the kernel to handle Speedstep changes. Normally, CPU speed changes won't affect anything, as users of older laptops will know. However, as the kernel uses timing loops for some things, if the speed of your CPU changes you might experience problems when changing CPU speed, since the timing loops won't be the right duration.
That's why the speedstep changes are in there, to recalibrate the loops when the CPU changes speed. If the new CPUs use a different method to notify speed changes (or whatever, I'm not precisely sure how it works), another case will probably have to be added but it should be minimal. And running Linux before such changes are made will probably be pretty safe, you'll just have a potential for problems.
(I think the speedstep changes are in all recent 2.2 kernels, but I don't think they're user-visible in any way.)
SpeedStep: I do not think that chip does what you think it does. And it doesn't ship with Iocaine powder, either.
:)
SpeedStep runs at the lower speed WHENEVER you are on battery. (at least according to Dell) It is not dependent on the processes going on. It only runs at the higher speed when plugged in. imo, this is idiotic. But I can see how it would reduce OS problems.
Transmeta's processor does a much swifter thing; it changes dynamically based roughly on usage... so when you aren't using it, it just slows down.
This is better, but I'm not sure how much, than those programs which simply send the least-power-using instruction for a cycle to reduce heat load. Since heat load = power input (because all is eventually heat) such a program should significantly reduce your power usage, BUT it depends on the OS working right... I suspect that actually slowing down the number of operations is much more efficient than the lowest op, because I bet there's a bunch of overhead even on the lowest-power operation. So Transmeta's is definitely better.
I haven't researched PowerNow. But I bet it isn't stupid like SpeedStep. So I'm betting on a Transmeta style approach, where it dynamically changes it based on load. (Of course, the response time and load analysis algorithm are going to be important, and you should really set up all your backup maintenance progs to only run on AC power... along with RC5
So that's why it would screw with Linux, and SpeedStep won't (fewer changes... possibly even only on boot...) However, I can't imagine a technique which would be MORE disruptive than transmeta's (except possibly for changing faster...) so I'd imagine that if Transmeta works it'd be fine.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Alan Cox wrote:
> > Correct. Transmeta Longrun and Intel Speedstep do change the clock
> > frequency, though; however, at least Transmeta will still present a
> > constant-frequency TSC to the RDTSC instruction. Don't know about
> > Intel.
>
> I believe Intel also keeps constant TSC.
>
> > (Now, some broken Cyrix chips would lose or not increment the TSC when
> > throttled.)
>
> They stop the TSC when the CPU is suspended completely. Thats actually very
> nice behaviour on a power sensitive device.
2.2.16 and beyond support SpeedStep, et al.
I can't actually provide links, but I can provide some Linux common-knowledge.
As most Linux specialists probably know, the kernel calculates a rough estimate of the system's speed in BogoMIPs (bogus MIPs) when it is first initialized. This figure probably gets used a lot for imposing delays etc., especially I/O wise, where an I/O wait period is much smaller than the x86 clock chip's maximum speed. I can't be 100% certain of this because I'm not a mighty kernel hacker yet =P.
A word of technical detail on the x86 clock chip (skip if bored): every x86 chipset since the PC (I think) has at the very least a single system clock chip on it which gets split into three separate clock master signals. One is for DRAM Refresh (so you can't monkey with that one--much); another is equally vital, although I don't remember exactly what it does. The third is spare for system use, but is by default used for maintaining the BIOS software clock, whether a Real Time Clock (RTC) circuit is present or not.
This third signal can be set to a pretty high frequency, but it is sometimes not high enough to impose I/O wait periods in hardware drivers without making those wait periods longer than necessary and impacting system performance. I think this is usually where BogoMIPs get used...
The bad thing about BogoMIPs is that they are only a rough figure of performance and often get used as a more precise measure than they really are (usually not in a stable kernel though).
The bad thing about BogoMIPs and PowerNow is that BogoMIPs will become even *less* accurate than before. This is probably a very serious problem, as up until now, the kernel has been able to assume that a CPU will stay at the same speed it had at boot time and thus assume a fair degree of consistency in the actual BogoMIPs rate at any time. This assumption is no longer valid with PowerNow.
So...my guess is that this PowerNow thing WILL cause a severe problem--not just with Linux, but possibly with many other operating systems as well. This problem could be worked out, though; the kernel is capable of monitoring CPU clock frequency, so that clock speed at any given time, combined with clock speed at the time of BogoMIPs calculation, could be used to calculate a factor to apply to the original BogoMIPS calculation and thus get a fairly accurate current BogoMIPS calculation. This would probably impact performance a bit.
I'd guess that in future kernels, you would see the "Support PowerNOW!" config option within the CPU Features submenu of the kernel config script. For those who don't know about this (and are actually interested in knowing), check the Kernel-HOWTO at Linuxdoc.org .
Hoo...all that karma whoring. I feel dirty now...I think I'll take a shower.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
Great troll, though.
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
SpeedStep runs at the lower speed WHENEVER you are on battery. (at least according to Dell) It is not dependent on the processes going on. It only runs at the higher speed when plugged in. imo, this is idiotic. But I can see how it would reduce OS problems.
SpeedStep is configurable. From what I understand of SpeedStep, software has to initate the change. With Windows, a control panel applet watches the power source with APM, and when it changes, it has the option of changing the speed. With the Windows applet, it allows you to configure SpeedStep to run at full speed all the time, only when on AC power, or never. Likewise, it lets you configure the lower speed all the time, only on battery, or never.
The system will also switch on-the-fly. While configured to run slow on battery and fast on AC, use a program to measure CPU speed on both and it will change as the power source changes.
Transmeta's processor does a much swifter thing; it changes dynamically based roughly on usage... so when you aren't using it, it just slows down.
This is better than SpeedStep, but the Intel CPUs do have a nice feature called the HLT instruction, which actually halts the CPU until an external interrupt occurs. If Windows 9x would actually use it, laptop batteries would last ALOT longer.
This is better, but I'm not sure how much, than those programs which simply send the least-power-using instruction for a cycle to reduce heat load. [snip] I suspect that actually slowing down the number of operations is much more efficient than the lowest op, because I bet there's a bunch of overhead even on the lowest-power operation. So Transmeta's is definitely better.
This is better when used unaided with Windows 9x/Me. But...
Like I mentioned above, the HLT instruction will actually stop ALL instruction processing within the CPU until an external interrupt occurs, ie. the timer interrupt fires so the OS can schedule the next process. So, once the HLT instruction is issued, the CPU remains halted for the remainder of the processes timeslice. HLT is used within the idle process of Linux, the BSDs, and Win NT/2000, so they all benefit. For Win9x, there are programs like Rain, that will consume all of the idle CPU time and issue HLT instructions as if it was the idle process.
If Transmeta's chip can halt itself when it detects an idle loop, then cool. It should work quite a bit better with Win9x than other x86 CPUs.