When you think of kids on the playground playing Star Trek make-believe, you see the guy who plays Scotty inevitably being shouted at to increase or decrease the power, and then the guy putting on his best (or worst) Scottish accent and complaining back to the captain about how it canna be done, she can't take this abuse much longer or we're all genna bloe! Powering up and powering down is the most common task that amateurs think of when they consider the role of an engineer running a big machine.

And yet up until very recently, servers have existed in a perpetual "on/off" state -- they're either turned on and consuming the energy they've been designed to consume, or they're off and your data center is offline. Only in the last few years, with the introduction of the multicore era coupled with the sudden ubiquity of virtualization, has there been the notion that you can move the entire serving job at any one time to the most efficient processor available. New CPU technologies like Intel SpeedStep have created the opportunity for administrators to eliminate the problem of processor latency by turning off entire cores when they're not in use.

Beginning with both Windows Server 2008 R2 and Windows 7, Microsoft will build that capability directly into the operating system, with the addition of new parameters to the powercfg command-line tool. Believe it or not, powercfg made its debut in Windows XP SP2 (yes, the client, not the server), as a tool for reporting the power profile of systems such as laptops that frequently suffer from low battery life.

In WS2K8 R2, powercfg takes on the role of a PowerShell cmdlet (though it can still run from CMD.EXE; if Microsoft's engineers had really gone all out with the cmdlet idea, they'd have created an alias "set-power" in accordance with PowerShell's grammar guidelines). This tool will now communicate directly with the operating system's new processor performance management (PPM) engine, which has the capability (assuming the underlying CPUs support it, and both new AMD Opterons and new Intel Xeons do) to turn down or off minimally used, underutilized, or unused processor cores.

For now, in lieu of a management console plug-in, and also instead of group policies (which Microsoft had promised, but which conceivably a third party may write using an SDK), R2 will provide administrators with a simple syntax for setting limits on when and how PPM can park unused cores or reduce processor frequency. You'll find it easier to use powercfg from PowerShell because you'll need to use the get-processor cmdlet to locate the GUID of the CPU to whose settings you'll be referring; you'll be referring to WMI, and it's just easier to create a variable that grabs the WMI object, rather than retyping the GUID from scratch.

As an obscure, but obtainable, new piece of Microsoft documentation explains it, "The PPM engine chooses a minimum number of cores on which threads will be scheduled. Cores that are chosen to be 'parked' do not have any threads scheduled on them and they can drop into a lower power state. The remaining set of 'unparked' cores are responsible for the entirety of the workload (with the exception of affinitized work or directed interrupts). Core parking can increase power efficiency during lower usage periods on the server because parked cores can drop into a low-power state."

Using powercfg, you create a power scheme (which is separate from a group policy object), and you give that scheme a name like ordinary_scheme. You may have already been doing this before for regular system power management. But now, the scheme adds a sub_processor parameter with which you designate the integer percentage of cores in your system (remember, a single R2 instance can now support 256 logical cores simultaneously) that can be regulated through PPM. If it just so happens that all the cores being powered down reside on the same die, PPM can take the next logical step and power down the whole chip, if necessary. In this type of regulation -- again, if your CPUs support it -- the various range of supported frequencies, known as ACPI p-states, can be tapped into to reduce the frequencies of underutilized cores at will, and power them back up again when the load gets heavier.

Early beta testers who had not been informed of this new feature had actually been alarmed by the discovery that several of their processor cores were not registering heartbeats in Resource Monitor. What's the matter with Resource Monitor, they asked? Nothing at all, it turns out...and with the shipping version, Resource Monitor will allay admins' concern by explicitly reporting shut down cores as "Parked," with grey text.