OPTIMIZING BOOT-TIME PEAK POWER CONSUMPTION FOR SERVER/RACK SYSTEMS

Methods and apparatus relating to optimizing boot-time peak power consumption for server and/or rack systems are described. In an embodiment, a module execution sequence for a computing device is determined to indicate a sequence of module execution during a boot process of the computing device. The module execution sequence is determined based at least partially on power consumption data and timeline data for each module of the computing device during the boot process of the computing device. Other embodiments are also claimed and described.

FIELD

The present disclosure generally relates to the field of computing. More particularly, an embodiment generally relates to optimizing boot-time peak power consumption for server and/or rack systems.

BACKGROUND

When designing the power budget for a rack system's power supply, designers account for the maximum possible power consumption, which usually happens at server boot time. The worst case is when all mounted servers in a rack are powered up or rebooted at the same time. A server's peak power consumption happens only at some specific moments during boot process and may last tens of seconds and generally no longer than minutes. As such, a rack's power supply has to be capable enough to serve this peak power moment even though such usage is infrequent and for a relatively short duration. This raises the power supply cost and makes the rarely used headroom capacity a waste of resources.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments. Further, various aspects of embodiments may be performed using various means, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs (“software”), or some combination of hardware and software. For the purposes of this disclosure reference to “logic” shall mean either hardware, software, firmware (FM), or some combination thereof.

Some embodiments provide techniques for optimizing boot-time peak power consumption for server and/or rack systems. Moreover, techniques discussed herein with reference to a “rack” system may be also applied to other types of server configurations. Also, as discussed above, when designing the power budget for a rack system's power supply (also referred to as a PSU or Power Supply Unit), designers account for the maximum possible power consumption. This in turn raises the electricity bill a server owner has to pay and the rack PSU cost, and makes the rarely used headroom capacity a waste of resources. To this end, an embodiment provides a way to lower a rack's peak power consumption without compromising each server's boot performance. This will in turn allow for the use of a lower capacity and cheaper rack PSU. Furthermore, costs may be reduced for the PSU, through power consumption reduction, and/or for rack space (especially when we consider how much can be saved in modern data centers where tens of thousands of racks are deployed).

In some embodiments, information regarding when and which BIOS (Basic Input Output System) module causes how much power consumption on each server is identified and logged/stored. Based on this information, it is determined how to coordinate among all target servers to adjust module execution sequence on each server and as a result lower the overall peak power consumption for all target servers during their respective boot process. For example, boot data may be automatically collected and the information used to compute and provide results to optimize boot sequence on target servers without human intervention. Such an approach would be highly productive and may be applied on any scale of servers with any hardware configurations, without reducing boot performance.

Moreover, certain initialization ordering during the boot process may have to be maintained, e.g., to maintain operational correctness. For example, the memory controller may need to be initialized before the memory to allow for access to the memory.

As discussed herein, a BIOS module refers to a component (such as software components/logic discussed herein with reference to various computing systems, including those ofFIGS. 4-6) whose execution sequence during boot time is configurable (e.g., via BIOS). Moreover, some embodiments may utilize UEFI (Unified Extensible Firmware Interface) to configure the hardware modules to cause different power consumption levels. Additionally, one or more sensors (not shown) which may be thermally proximate or thermally coupled to the module(s) may be used to detect the power consumption and timeline data discussed herein to detect the power consumption data and timeline data during the boot process.

Furthermore, while some embodiments are discussed with server/rack systems, embodiments are not limited to such high volume architectures and may be applied to smaller systems, e.g., with multiple processors or other components that use significantly more power during boot time than during runtime.

To describe details of various embodiments, assume a simplified rack system with two servers mounted (Server1and Server2shown inFIGS. 1-2).FIG. 1illustrates sample graphs showing power behavior of the two servers versus the rack without optimization, according to some implementations.FIG. 1shows the power behavior when both servers are booting up at the same time, with the individual and summed power consumption illustrated.

Referring toFIG. 1, A, B, and C are BIOS modules on server1, while X, Y, and Z are BIOS modules on server2. The start and end time of module A, B, and C execution are respectively {[0, 10], [10, 16], [16, 25]}. Power consumption of modules A, B, and C is {5, 10, 18}. The start/end time of modules X, Y, Z are respectively {[0, 7], [7, 18], [18, 26]} and power consumption of modules X, Y, and Z is {15, 8, 17}.

The start/end time and power consumption of each module on each server can all be determined from a boot log. Rack power consumption is then the sum of power consumption of server1and server2. So, when both servers are powering up, the rack peak power consumption occurs at [18, 25], the peak value is 18+17=35. It is when module C on server1and module Z on server2are executed.

To this end, an embodiment optimizes the module execution sequence on each server. For example, in the case ofFIG. 1, if we adjust module execution sequence of server2from X->Y->Z to X->Z->Y, then the graphs ofFIG. 1change to those ofFIG. 2, which illustrate sample graphs showing power behavior of the two servers versus the rack with optimization, according to an embodiment.

As can be seen inFIG. 2, the rack peak power happens at [10, 15] when module B on server1and module Z on server2are executing, the peak value is now 10+17=27, lower down from 35 in original execution sequence ofFIG. 1. Further, at rack level, we have some new time periods like [0, 7], [7, 10], [10, 15] . . . etc., which may be referred to herein as “time quantum” to differentiate from original module execution time periods.

The examples ofFIGS. 1-2only deal with a simplified case, whereas a more realistic scenario may involve a rack with tens of servers and each server having different hardware components (providing different BIOS modules with various duration and power consumption). To this end, the rest of the document discusses a more generalized approach to deal with more general cases.

FIGS. 3A-3Cillustrate flow diagrams of methods for optimizing boot-time peak power consumption for various computing systems (such as server and/or rack systems), according to some embodiments. One or more components (such as processor(s), logic, and/or memory) discussed with reference toFIGS. 4-6may be utilized to perform one or more of the operations discussed with reference toFIGS. 3A-3C.

Referring toFIG. 3A, after initial system installation or upon changing/replacing a server and/or one or more components, during operation302, the involved server(s) are powered on and the boot log(s) (such as the information discussed with reference toFIGS. 1-2) stored. At an operation304, the boot log(s) are sent to a central place which could be any dedicated server or a node manager logic (or other logic). At an operation306, computation(s) are performed as will be further discussed with reference toFIG. 3B.

At an operation308, a new module dispatch sequence is determined for every involved server(s) (e.g., based on the computations/determinations of operation306). At an operation310, each of the dispatch sequence of operation308is sent back to the corresponding server (and the dispatch sequence information is stored in a storage unit, which is either local to the corresponding server or otherwise accessible by the corresponding server during its boot process (such as in flash or other type of non-volatile memory)). At an operation312, next time any of the server(s) of operation310boot or reboot, the new module dispatch sequence of operation308will be applied.

Referring toFIG. 3B, at an operation320, start/end time information and power consumption information of each BIOS module of all involved servers (such as the information discussed with reference toFIGS. 1-2) are stored. As discussed herein, start/end time of x-th server with #N module is represented as: {[h1x, t1x], [h2x, t2x] . . . [hNx, tNx]}.

At an operation322, two servers A and B, are picked from all the servers, where server A has #J modules and server B has #K modules. At an operation324, for A and B, an optimized execution sequence is computed which can generate lower peak power consumption for A and B. The generated new timeline Q has the illustrated time quantums. At an operation326, it is determined whether all involved servers are done.

As long as all servers are not done at operation326, at an operation328, a server R from the rest of the servers (all servers other than A and B) is picked. Then, this new R server is treated as server A in the former operation324as shown inFIG. 3Bat operation328. At an operation330, Q is treated as server B in the former case, such as shown inFIG. 3B. At an operation332, the new A and B for the next iteration are ready and method306resumes at operation324.

Once all servers are done, as determined at operation326, an operation334, the optimized module dispatch sequence for all servers has been found and are sent to each server at operation336.

Referring toFIG. 3C(which shows details of operation324ofFIG. 3B, in accordance with an embodiment), at an operation350, the timelines are determine as shown inFIG. 3Cin box350. At an operation352, the timeline for A and B are built and the current peak power is determined, indicating which module of server B is executing when combined peak power is reached (referred to as module H). After an operation354, the next speculative start point for module H is picked from server B's timeline. At an operation356, module H's start time is placed at the current speculative start point and all other server B's modules are put after H (without changing anything else). At an operation358, current peak power of server A and server B are calculated and stored. Also, current B's module execution sequence is stored at operation358.

If the current peak power is lower than any previously determined peak powers for module H (e.g., as determined at operation360), then server B's current execution sequence is recorded as the optimal sequence for server B at an operation362; otherwise, it is determined whether all speculative start points for H module have been considered at an operation364. If other speculative start points remain for H module, method324resumes at operation354. Otherwise, at an operation366, server B's best module execution sequence is used as its new execution sequence (at this point server A and server B have an optimize module execution sequence). At an operation368, the generated new timeline for servers A and B are recorded, as shown in box368ofFIG. 3C. Have an operation370the optimization for servers A and B are done (and the flow transfers to operation326ofFIG. 2B).

FIG. 4illustrates a block diagram of a computing system400in accordance with an embodiment. The computing system400may include one or more central processing unit(s) (CPUs)402or processors that communicate via an interconnection network (or bus)404. The processors402may include a general purpose processor, a network processor (that processes data communicated over a computer network403), or other types of a processor (including a reduced instruction set computer (RISC) processor or a complex instruction set computer (CISC)).

Moreover, the processors402may have a single or multiple core design. The processors402with a multiple core design may integrate different types of processor cores on the same integrated circuit (IC) die. Also, the processors402with a multiple core design may be implemented as symmetrical or asymmetrical multiprocessors. Additionally, the operations discussed with reference toFIGS. 1-3may be performed by one or more components of the system400. Also, various devices discussed with reference toFIGS. 1-3C(such as the desktop, smartphone, tablet, UMPC (Ultra-Mobile Personal Computer), laptop computer, Ultrabook™ computing device, smart watch, smart glasses, server, rack, etc.) may include one or more of the components ofFIG. 4.

For example, memory412may store the information discussed with reference toFIGS. 1-3Cand one or more of the operations discussed with reference toFIGS. 1-3Cmay be executed on processor(s)402. Also, system400may include an image capture device. Moreover, the scenes, images, or frames (e.g., which may be processed by the graphics logic in various embodiments) may be captured by the image capture device (such as a digital camera (that may be embedded in another device such as a smart phone, a tablet, a laptop, a stand-alone camera, etc.) or an analog device whose captured images are subsequently converted to digital form). Moreover, the image capture device may be capable of capturing multiple frames in an embodiment. Further, one or more of the frames in the scene are designed/generated on a computer in some embodiments. Also, one or more of the frames of the scene may be presented via a display (such as display416, including for example a flat panel display device, etc.).

A chipset406may also communicate with the interconnection network404. The chipset406may include a Graphics and Memory Control Hub (GMCH)408. The GMCH408may include a memory controller410that communicates with a memory412. The memory412may store data, including sequences of instructions, that may be executed by the CPU402, or any other device included in the computing system400. In one embodiment, the memory412may include one or more volatile storage (or memory) devices such as random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), or other types of storage devices. Nonvolatile memory may also be utilized such as a hard disk. Additional devices may communicate via the interconnection network404, such as multiple CPUs and/or multiple system memories.

The GMCH408may also include a graphics interface414that communicates with a display device416. In one embodiment, the graphics interface414may communicate with the display device416via an accelerated graphics port (AGP) or Peripheral Component Interconnect (PCI) (or PCI express (PCIe) interface). In an embodiment, the display416(such as a flat panel display) may communicate with the graphics interface414through, for example, a signal converter that translates a digital representation of an image stored in a storage device such as video memory or system memory into display signals that are interpreted and displayed by the display416. The display signals produced by the display device may pass through various control devices before being interpreted by and subsequently displayed on the display416.

A hub interface418may allow the GMCH408and an input/output control hub (ICH)420to communicate. The ICH420may provide an interface to I/O device(s) that communicate with the computing system400. The ICH420may communicate with a bus422through a peripheral bridge (or controller)424, such as a peripheral component interconnect (PCI) bridge, a universal serial bus (USB) controller, or other types of peripheral bridges or controllers. The bridge424may provide a data path between the CPU402and peripheral devices. Other types of topologies may be utilized. Also, multiple buses may communicate with the ICH420, e.g., through multiple bridges or controllers. Moreover, other peripherals in communication with the ICH420may include, in various embodiments, integrated drive electronics (IDE) or small computer system interface (SCSI) hard drive(s), USB port(s), a keyboard, a mouse, parallel port(s), serial port(s), floppy disk drive(s), digital output support (e.g., digital video interface (DVI)), or other devices.

The bus422may communicate with an audio device426, one or more disk drive(s)428, and a network interface device430(which is in communication with the computer network403). Other devices may communicate via the bus422. Also, various components (such as the network interface device430) may communicate with the GMCH408in some embodiments. In addition, the processor402and the GMCH408may be combined to form a single chip and/or a portion or the whole of the GMCH408may be included in the processors402(instead of inclusion of GMCH408in the chipset406, for example). Furthermore, the graphics accelerator416may be included within the GMCH408in other embodiments.

Furthermore, the computing system400may include volatile and/or nonvolatile memory (or storage). For example, nonvolatile memory may include one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), a disk drive (e.g., item428), a floppy disk, a compact disk ROM (CD-ROM), a digital versatile disk (DVD), flash memory, a magneto-optical disk, or other types of nonvolatile machine-readable media that are capable of storing electronic data (e.g., including instructions).

In an embodiment, components of the system400may be arranged in a point-to-point (PtP) configuration such as discussed with reference toFIG. 5. For example, processors, memory, and/or input/output devices may be interconnected by a number of point-to-point interfaces.

More specifically,FIG. 5illustrates a computing system500that is arranged in a point-to-point (PtP) configuration, according to an embodiment. In particular,FIG. 5shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. The operations discussed with reference toFIGS. 1-4may be performed by one or more components of the system500.

As illustrated inFIG. 5, the system500may include several processors, of which only two, processors502and504are shown for clarity. The processors502and504may each include a local memory controller hub (MCH)506and508to enable communication with memories510and512. The memories510and/or512may store various data such as those discussed with reference to the memory412ofFIG. 4.

In an embodiment, the processors502and504may be one of the processors402discussed with reference toFIG. 4. The processors502and504may exchange data via a point-to-point (PtP) interface514using PtP interface circuits516and518, respectively. Also, the processors502and504may each exchange data with a chipset520via individual PtP interfaces522and524using point-to-point interface circuits526,528,530, and532. The chipset520may further exchange data with a graphics circuit534via a graphics interface536, e.g., using a PtP interface circuit537.

At least one embodiment may be provided within the processors502and504. Also, the operations discussed with reference toFIGS. 1-4may be performed by one or more components of the system500. For example, memory510/512may store the information discussed with reference toFIGS. 1-3Cand one or more of the operations discussed with reference toFIGS. 1-3Cmay be executed on processor(s)502/504. Also, various devices discussed with reference toFIGS. 1-4(such as the desktop, smartphone, tablet, UMPC (Ultra-Mobile Personal Computer), laptop computer, Ultrabook™ computing device, smart watch, smart glasses, server, rack, etc.) may include one or more of the components ofFIG. 5.

Other embodiments, however, may exist in other circuits, logic units, or devices within the system500ofFIG. 5. Furthermore, other embodiments may be distributed throughout several circuits, logic units, or devices illustrated inFIG. 5.

The chipset520may communicate with a bus540using a PtP interface circuit541. The bus540may communicate with one or more devices, such as a bus bridge542and110devices543. Via a bus544, the bus bridge542may communicate with other devices such as a keyboard/mouse545, communication devices546(such as modems, network interface devices, or other communication devices that may communicate with the computer network403), audio I/O device547, and/or a data storage device548. The data storage device548may store code549that may be executed by the processors502and/or504.

In some embodiments, one or more of the components discussed herein can be embodied as a System On Chip (SOC) device.FIG. 6illustrates a block diagram of an SOC package in accordance with an embodiment. As illustrated inFIG. 6, SOC602includes one or more Central Processing Unit (CPU) cores620, one or more Graphics Processor Unit (GPU) cores630, an Input/Output (I/O) interface640, and a memory controller642. Various components of the SOC package602may be coupled to an interconnect or bus such as discussed herein with reference to the other figures. Also, the SOC package602may include more or less components, such as those discussed herein with reference to the other figures. Further, each component of the SOC package620may include one or more other components, e.g., as discussed with reference to the other figures herein. In one embodiment, SOC package602(and its components) is provided on one or more Integrated Circuit (IC) die, e.g., which are packaged into a single semiconductor device.

As illustrated inFIG. 6, SOC package602is coupled to a memory660(which may be similar to or the same as memory discussed herein with reference to the other figures) via the memory controller642. In an embodiment, the memory660(or a portion of it) can be integrated on the SOC package602.

The I/O interface640may be coupled to one or more I/O devices670, e.g., via an interconnect and/or bus such as discussed herein with reference to other figures. I/O device(s)670may include one or more of a keyboard, a mouse, a touchpad, a display (e.g., display416), an image/video capture device (such as a camera or camcorder/video recorder), a touch screen, a speaker, or the like.

The following examples pertain to further embodiments. Example 1 includes an apparatus comprising: logic to determine a module execution sequence for a computing device to indicate a sequence of module execution during a boot process of the computing device, wherein logic to determine the module execution sequence is to determine the module execution sequence based at least partially on power consumption data and timeline data for each module of the computing device during the boot process of the computing device. Example 2 includes the apparatus of example 1, wherein logic to determine the module execution sequence for the computing device is to determine a plurality of module execution sequences for a plurality of computing devices based on power consumption data and timeline data for each module of each of the plurality of the computing devices during boot process of the plurality of computing devices. Example 3 includes the apparatus of example 2, wherein the plurality of computing devices are to be coupled via a rack system. Example 4 includes the apparatus of example 1, wherein the module is capable of having its execution sequence modified during the boot process. Example 5 includes the apparatus of example 1, wherein logic to determine the module execution sequence for the computing device is to determine the module execution sequence based on one or more speculative start points for each module of the computing device. Example 6 includes the apparatus of example 1, further comprising one or more sensors to detect the power consumption data and timeline data during the boot process. Example 7 includes the apparatus of example 1, wherein the module is capable of having its execution sequence modified during the boot process via a Basic Input Output System (BIOS). Example 8 includes the apparatus of example 1, wherein the module is capable of having its execution sequence modified during the boot process via a Unified Extensible Firmware Interface. Example 9 includes the apparatus of any of examples 1 to 8, wherein the logic, memory, and one or more processor cores are on a single integrated circuit device.

Example 10 includes a method comprising: determining a module execution sequence for a computing device to indicate a sequence of module execution during a boot process of the computing device, wherein determining the module execution sequence determines the module execution sequence based at least partially on power consumption data and timeline data for each module of the computing device during the boot process of the computing device. Example 11 includes the method of example 10, further comprising determining a plurality of module execution sequences for a plurality of computing devices based on power consumption data and timeline data for each module of each of the plurality of the computing devices during boot process of the plurality of computing devices. Example 12 includes the method of example 11, wherein the plurality of computing devices are coupled via a rack system. Example 13 includes the method of example 10, wherein the module is capable of having its execution sequence modified during the boot process. Example 14 includes the method of example 10, further comprising determining the module execution sequence based on one or more speculative start points for each module of the computing device. Example 15 includes the method of example 10, further comprising one or more sensors detecting the power consumption data and timeline data during the boot process. Example 16 includes the method of example 10, further comprising the module having its execution sequence modified during the boot process via a Basic Input Output System (BIOS). Example 17 includes the method of example 10, further comprising the module having its execution sequence modified during the boot process via a Unified Extensible Firmware Interface.

Example 18 includes a computing system comprising: one or more Central Processing Unit (CPU) cores; one or more Graphics Processor Unit (GPU) cores, wherein the one or more CPU or GPU cores are to be supplied power from a power supply unit; logic to determine a module execution sequence for a computing device to indicate a sequence of module execution during a boot process of the computing device, wherein the power supply unit is to provide power to each module of the computing device during the boot process of the computing device, wherein logic to determine the module execution sequence is to determine the module execution sequence based at least partially on power consumption data and timeline data for each module of the computing device during the boot process of the computing device. Example 19 includes the system of example 18, wherein logic to determine the module execution sequence for the computing device is to determine a plurality of module execution sequences for a plurality of computing devices based on power consumption data and timeline data for each module of each of the plurality of the computing devices during boot process of the plurality of computing devices. Example 20 includes the system of example 18, wherein the module is capable of having its execution sequence modified during the boot process. Example 21 includes the system of example 18, wherein logic to determine the module execution sequence for the computing device is to determine the module execution sequence based on one or more speculative start points for each module of the computing device. Example 22 includes the system of example 18, further comprising one or more sensors to detect the power consumption data and timeline data during the boot process. Example 23 includes the system of example 18, wherein the module is capable of having its execution sequence modified during the boot process via a Basic Input Output System (BIOS).

Example 24 includes an apparatus comprising means for performing a method as provided in any of examples 10 to 17.

Example 25 includes a machine-readable storage including machine-readable instructions, when executed, to implement a method or realize an apparatus as provided in any of examples 10 to 17.

Example 26 includes a computer-readable medium comprising one or more instructions that when executed on a processor configure the processor to perform one or more operations to: determine a module execution sequence for a computing device to indicate a sequence of module execution during a boot process of the computing device, wherein determining the module execution sequence determines the module execution sequence based at least partially on power consumption data and timeline data for each module of the computing device during the boot process of the computing device. Example 27 includes the computer-readable medium of example 26, further comprising one or more instructions that when executed on the processor configure the processor to perform one or more operations to cause determining a plurality of module execution sequences for a plurality of computing devices based on power consumption data and timeline data for each module of each of the plurality of the computing devices during boot process of the plurality of computing devices. Example 28 includes the computer-readable medium of example 26, wherein the module is capable of having its execution sequence modified during the boot process. Example 29 includes the computer-readable medium of example 26, further comprising one or more instructions that when executed on the processor configure the processor to perform one or more operations to cause determining the module execution sequence based on one or more speculative start points for each module of the computing device. Example 30 includes the computer-readable medium of example 26, further comprising one or more instructions that when executed on the processor configure the processor to perform one or more operations to cause one or more sensors detecting the power consumption data and timeline data during the boot process. Example 31 includes the computer-readable medium of example 26, further comprising one or more instructions that when executed on the processor configure the processor to perform one or more operations to cause the module having its execution sequence modified during the boot process via a Basic Input Output System (BIOS). Example 32 includes the computer-readable medium of example 26, further comprising one or more instructions that when executed on the processor configure the processor to perform one or more operations to cause the module having its execution sequence modified during the boot process via a Unified Extensible Firmware Interface. Example 33 includes the apparatus of any of examples 1 to 6 or 8, wherein the module is capable of having its execution sequence modified during the boot process via a Basic Input Output System (BIOS).

In various embodiments, the operations discussed herein, e.g., with reference toFIGS. 1-6, may be implemented as hardware (e.g., logic circuitry), software, firmware, or combinations thereof, which may be provided as a computer program product, e.g., including a tangible (such as a non-transitory) machine-readable or computer-readable medium having stored thereon instructions (or software procedures) used to program a computer to perform a process discussed herein. The machine-readable medium may include a storage device such as those discussed with respect toFIGS. 1-6(including, for example, ROM, RAM, flash memory, hard drive, solid state drive, etc.).

Additionally, such computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals provided in a carrier wave or other propagation medium via a communication link (e.g., a bus, a modem, or a network connection).

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, and/or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase “in one embodiment” in various places in the specification may or may not be all referring to the same embodiment.