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?"

Comments

Links please

[funkman]

Can someone with insight do some Karma whoring and get some references to this topic?

Re:Links please

[Kelledin]

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

Re:Links please

[angry old man]

Bagh! All you kids think that you are developing 'new' technology with all your fancy schmancy 'speed changing CPUs'.

Back in my day, we had computers that ran at different speeds. They had a TURBO button. The computer that I'm typing this on runs at an adequate 40 MHz. When I have to do some computing or send a document to the printer, then I press the TURBO button and the document gets queued in the printer at a blazing 55 MHz.

This computer is as fast as you need once it's in Turbo mode and it's over 10 years old!

Re:Links please

[rabidcow]

the pit (programmable interrupt timer) on the original pcs had 3 channels. channel 0 was used for updating the system clock (not the cmos clock), channel 1 was used for dram refresh, and channel 2 was used to generate tones for the pc speaker.

AMD Embedded

[gormanly]

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.

Exactly why I stay away from AMD.

[AFCArchvile]

they're always "innovating" by putting on little features to their CPUs that end up requiring either a driver upgrade or an entire operating system patch. When Intel gets their act together, I might consider getting a new system. Of course, that might take about three years...

Intel SpeedStep?

[Enry]

How is this different from Intel's Speed Step that slows a chip down from 650 to 500?

ummm..no.

[Zurk]

linus didnt have to make changes for the transmeta CPUs....the clock changes are transparent to the OS. As AMDs will probably be the same ...Intels SpeedStep definitely is, since my machine varies its clock and the OS (Linux/FreeBSD) doesnt notice.

Some changes probably desired

[Alan Shutko]

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 vs PowerNow vs Transmeta karma whoring

[arete]

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.

not a problem

[Anonymous Coward]

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.

what are you smoking?

[Wakko Warner]

The only patches I've ever seen for a CPU are for the "innovative" Intel f00f and MTH bugs. Every single AMD cpu I've ever used has worked perfectly with Linux, no matter what version.

Great troll, though.

- A.P.

--
* CmdrTaco is an idiot.

Re:what are you smoking?

[Smaon]

There has to be a kernel patch for the Athlon (at least some old kernels (for example the RH6.? install disk...) refuse to work with it). I've heard that this is because the Athlon doesn't have the CPU serial number of Intels PIII and if the kernel wants to disable it it generates an error ....

Re:what are you smoking?

[atallah]

yeah i heard about that too..

and who's fault is that?? Not AMD i would think!

PowerNow can be disabled.

[acidblood]

I read in some (p)reviews that PowerNow can be disabled through the included software... Whether that means the feature is hardware-disabled or that it's software controlled and the software itself is disabled, I can't comment on.

Re: SpeedStep vs Transmeta

[jkf]

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.

Re: SpeedStep vs Transmeta

[arete]

If I had any moderator points (which I wouldn't 'cause it was a reply to my post, so obviously I posted) I'd mod you up.

Do you know whether Transmeta has or doesn't have HLT? While I didn't think of it in the two minutes I was writing that post, it sounds like something Transmeta's "next generation" powersaving they claim to have would probably contain... and I'd guess that PowerNow would have it, too... but I could certainly be wrong.

Re: SpeedStep vs Transmeta

[jkf]

Do you know whether Transmeta has or doesn't have HLT? While I didn't think of it in the two minutes I was writing that post, it sounds like something Transmeta's "next generation" powersaving they claim to have would probably contain... and I'd guess that PowerNow would have it, too... but I could certainly be wrong.

I would be surprised if it didn't contain HLT. HLT is part of the x86 instruction set, and all the other major CPU manufacturers have it. Besides, Linux uses it, so it must be in there. :)