Methods and system for managing a node's energy consumption

Abstract

A method for managing energy consumption of a node. The node comprises a processing unit (PU) comprising a first PU core and an uncore component. The method includes receiving, from an agent, container deployment information (CDI) for use in deploying on the node at least a first container assigned to at least the first PU core. The method also includes, in response to receiving the CDI from the agent, configuring the first PU core and / or the uncore component based on the CDI. The method further includes providing the CDI to a container engine (CE) (e.g., a container runtime).

Description

METHODS AND SYSTEM FOR MANAGING A NODE’ S ENERGY CONSUMPTIONTECHNICAL FIELD

[0001] Disclosed are embodiments related to managing the amount of energy consumed by a node.BACKGROUND

[0002] In the early days of the Internet, applications ran directly on top of the operating system (OS) of a node (e.g., a server), and defining resource boundaries for such applications was difficult, thereby causing resource allocation issues. For example, if multiple applications run on the same node, there can be instances where one application would take up most of the node processing resources, and as a result, the other applications would underperform.

[0003] One solution to this problem was to use virtual machines (VMs), were multipleVMs run on top of the OS and each application is run on one of the VMs. This virtualization allows applications to be isolated and provides a level of security as the information of one application cannot be freely accessed by another application. Virtualization also allows better utilization of resources. Each VM emulates a full machine running all the components, including its own operating system.

[0004] The “Container” Deployment Era.

[0005] Containers were the next step in the evolution of application deployment.Containers are similar to VMs, but they have relaxed isolation properties to share the operating system (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own file system, share of CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions. Containers have become popular and provide many benefits, hence many organizations have begun to use pods to bundle and run applications, where a pod is a collection of one or more containers.

[0006] As more and more organizations rely on containers to run applications, container orchestration systems have been developed to help manage the containers that run theapplications and ensure that there is no downtime. One example of such a container orchestration system is Kubernetes, which is an open-source container orchestration system for automating software deployment, scaling, and management.SUMMARY

[0007] Certain challenges presently exist. For instance, with respect to energy management, today’s container orchestration systems have shortcomings. For example, conventional container orchestration systems cannot configure core infrastructure (i.e., components a processing unit involved in executing instructions, such as, for example, the arithmetic logic unit (ALU), floating point unit (FPU), LI cache, L2 cache) or uncore infrastructure (i.e. the components of the processing unit not in the core, such as, for example, last level cache, memory controller, etc.) power management when deploying a pod. All pods (i.e., a collection of containers) are equally deployed with the same power management, independent of application needs this is also true for a virtualized deployment. This causes unnecessary high-power consumption when a service is the best effort and does not require highest performance. Additionally, the host OS on which the pods run cannot distinguish between best effort containers and guaranteed containers which need dedicated high- performance cores, and his causes unnecessary high-power consumption when service is best effort and does not require highest performance. Moreover, the host OS cannot measure the core utilization for services which use micro-sleep to save energy. The central processing unit (CPU) cores in micro-sleep states will be treated as fully loaded and cause the system to be in high performance state even if the service is idle. This leads to unnecessary high-power consumption for containers using micro-sleep function. With respect to frequency scaling, frequency scaling based on built-in host OS mechanisms causes reduced and un-deterministic performance, particular when applied to telecom applications. To guarantee the service level agreements, the telecom applications need a fast mechanism to scale from lowest to maximum performance state.

[0008] Another drawback of conventional systems, is that the CPU cannot distinguish if a high-prioritized container’s performance is limited by the core frequency or the uncore frequency, which leads to either the uncore frequency or the core frequency being unnecessarily high, which then leads to an unnecessary increase in power consumption. To save energy when a CPU hits a power limit, the system needs to either decrease the core frequency or uncorefrequency. As the system does not have any knowledge on how the applications scale, reduced uncore or core frequency could reduce application performance more than needed.

[0009] Further, while dynamic power management for Kubernetes is enabled with a system called Kepler (Kubernetes-based Efficient Power Level Exporter), Kepler has several shortcomings. Kepler does not use application information to configure power management. Kepler relies on infrastructure information and infrastructure counters and uses those to feed a machine learning model to configure power management, but does not describe that each application has different kind of needs. Some applications are able to handle standard host OS power management while others cannot meet the service requirements such as service response or packet latency when regular power management is applied. Kepler is designed to be generic, but the collection of hardware counters and the machine learning model need to be target specific. To configure power management efficiently, the machine learning algorithm needs to be application aware. Moreover, the collection of hardware counters using extended Berkeley Packet Filter (eBPF), running average power limit (RAPE) interface etc, cause kernel jitter and service latency that impact the running service. When deploying radio services, as an example, Kepler needs to be adapted to make sure that no kernel jitter impacts the performance of a critical container. The counters used in Kepler are collected via Prometheus and probably to slow to be used in run time to configure power management. To be fast, host OS or the infrastructure need to be configured from the beginning or using other API.

[0010] Accordingly, in one aspect there is provided a method for managing energy consumption of a node. The node comprises a processing unit (PU) comprising a first PU core and an uncore component. The method includes receiving, from an agent, container deployment information (CDI) for use in deploying on the node at least a first container assigned to at least the first PU core. In one embodiment, the CDI includes a first container image identifier for the first container and a PU core identifier for each PU core to which the first container is assigned. The CDI may also indicate a QoS class for the container (e.g., Guaranteed, Burstable, or Best Effort). In some embodiments, the CDI also includes the pod type metadata. The method also includes, in response to receiving the CDI from the agent, configuring the first PU core and / or the uncore component based on the CDI. The method further includes providing the CDI to a container engine (CE) (e.g., a container runtime). A CE is a function for deploying containers.

[0011] In another aspect there is provided a computer program comprising instructions which when executed by a processing unit of a node causes the node to perform any of the methods disclosed herein. In one embodiment, there is provided a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium. In another aspect there is provided a node that is configured to perform the methods disclosed herein. The node may include memory and a processing unit coupled to the memory.

[0012] An advantage of the embodiments disclosed herein is that they enable increased power savings (e.g. a power savings of up to 25-50%). Moreover, this power savings is achieved without impacting application performance, and, in fact, the power saving can be used to boost application performance. The embodiments can be used for packet processing applications that process packets in user space without any interaction with the operating system on which the application is running and server-based applications where the networking is provided by the operations system (e.g., via POSIX application programming interface (API)). Additionally, the embodiments enable improved peak system performance by maximizing usage out the power to boost core and uncore frequency. Energy is steered to services which require high-performance. By saving energy, the embodiments can reduce system cost (i.e., performance requirements can be met with fewer servers allocated). Finally, the embodiments can be used in conjunction with conventional container orchestration systems, including Kubernetes.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0014] FIG. 1 illustrates a system according to an embodiment.

[0015] FIG. 2 illustrates a node according to an embodiment.

[0016] FIG. 3 is a message flow diagram according to an embodiment.

[0017] FIG. 4 is a flowchart illustrating a process according to an embodiment.

[0018] FIG. 5 is a flowchart illustrating a process according to an embodiment.

[0019] FIG. 6 is a block diagram of the node according to an embodiment.DETAILED DESCRIPTION

[0020] FIG. 1 illustrates a system 100 according to an embodiment. System 100 includes a cluster 102 of nodes. In this example, cluster 102 includes three nodes, but in practice a cluster can have any number of nodes. System 100 also includes a control plane function (CPF) 104 for, among other things, deploying a pod to one or more nodes of cluster 102. In one specific embodiment, CPF 104 is a Kubemets application programming interface (API) server. As shown in FIG. 1, CPF may receive information specifying a pod (“pod information”) and may deploy the pod to node by sending to the node a deploy pod message, which includes the pod information or some of the pod information or information derived from the pod information. Table 1 below illustrates an example of pod information that may be received by CPF 104.Table 1

[0021] In the example pod information shown above, the pod includes only a single container (appcntrl) and indicates the quality-of-service (QoS) class for the container. For instance, in this case the total number of CPU cores needed for the container is 2 and the maximum number of CPU cores for the container is also 2, which indicates that the container has a QoS class of Guaranteed. If the CPU limit value is greater that the CPU requested value, then the container would have a QoS class of burstable, and if the pod information did not include a CPU requested value, then the contains would have a QoS class of best effort. Also, in the example shown above, the pod information includes metadata (i.e., an application hint label in this example) that indicates that the container is memory bound (i.e., the pod information includes the attribute-value-pair of “applicationlimit: membound). If the applicationlimit attribute was set to the value “corebound,” then the container would be core bound rather than memory bound. Accordingly, the metadata may include information indicating a pod type.

[0022] FIG. 2 illustrates an example node 200, which may be any one of the nodes of cluster 102. Node 200 includes a processing unit (PU) 212 (e.g., a CPU), which, in this example, includes an uncore component 214 (e.g., an interconnect fabric) and a group of core components (i.e., three CPU cores in this example: Corel 231, core2 232, and core3 234). An OS 216 runs on PU 212, and, as shown in FIG. 2, a number of applications run on top of OS 216, including: a container engine (CE) 222 (e.g., a container runtime) for deploying containers (e.g., containers cl, c2, c3, and c4), an energy management function (EMF) 220 for configuring PU 212 to increase energy savings, and an agent 218. While EMF 220 and agent 218 are shown as being separate applications, they can be combined into a single application (i.e., a single application may perform the functions of both EMF 220 and agent 218). Also, in some embodiments, instead of agent 218 being a component of node 200, agent is a component of CPF 104. As shown in FIG. 3, in one embodiment, agent 218 receives pod deployment requests from CPF 104. In embodiments in which CPF 104 is a Kubemetes API server and agent 218 runs on node 200, agent 218 may be a kublet.

[0023] The function of EMF 220 is to increase energy efficiency, particular when telecommunication grade containers are deployed on nodes of a cloud native infrastructure. As noted above, the CPF 104 and agent 218 may be standard Kubernetes components (i.e., API server and kublet, respectively). In such a scenario, EMF 220 can be considered a “shim” layer between agent 218 and CE 222, and the EMF 220 does not impact the Kubernetes components(i.e., no changes to the software is required) and is used to customize PU 212 before and after a pod deployment. In one embodiment, EMF 220 uses Kubemetes QoS classes and container characteristics to improve the energy efficiency of node 200.

[0024] For example, in one embodiment, EMF 220 controls the core frequency (P-states) and the halt states (C-states) on each PU core of PU 212 as well as the frequency of the uncore component 214 (e.g., an interconnect fabric) to provide the best energy efficient solution for each deployed container.

[0025] Accordingly, the role of EMF 220 is to use container deployment information (CDI) to configure power management and boost application performance by using energy in a more efficient way. EMF 220 can be added to any node when needed and can be either generic or specifically tailored to the service being provided by the node. For example, one could use use a telecommunication service specific EMF that can be applied in a standard kubemetes system merely by restarting the kubelet with a parameter to cause kubelet to communicate directly with the EMF rather than the CE. Accordingly, EMF 220 is non-intrusive as it does not impact the normal operations of the agent or the CE. Furthermore, EF 220 can boost the performance on critical micro- services by redirecting energy to the containers which need high real-time performance. EMF 220 can react quickly to traffic events.

[0026] As noted above, in some embodiments, EMF 220 can be considered a “shim” layer between agent 218 (e.g., kublet) and CE 222 (e.g., containerd).

[0027] In some embodiments, containers with Guaranteed QoS get dedicated cores while best effort and burstable containers share cores. In some embodiments, the functionality of EMF 220 may be built into agent 218 and / or CE 222.

[0028] FIG. 3 is a message flow diagram illustrating a process according to an embodiment for managing a node 200’ s energy consumption. As shown in FIG. 3, in one embodiment, as an initial configuration, EMF 220 configures PU 212 to be best effort. This initial configuration provides the lowest possible power consumption. In one embodiment, configuring a PU 212 be best effort comprises: setting the frequency for each PU core (“core frequency”) as low as possible, setting the frequency for uncore component 214 as low as possible, and enabling deep c-states on all PU cores. With this initial configuration, all PU cores(e.g., corel 231, core2 232, core3 233) are configured to be “best effort” and the node 200 is in a low power consumption state.

[0029] After PU 212 is placed into the best effort state, agent 118 may receive from CPF 104 a deploy pod request for deploying a pod (i.e., for deploying a collection of one or more containers). As noted above the deploy pod request may comprise pod information that was obtained by CPF 104 (e.g., the pod information shown in Table 1) or a subset of that pod information or information generated based on the pod information. In any event, in one embodiment, the deploy pod request comprises at least a container image identifier identifying a container image for a container and indicates a QoS class for the container. The deploy pod request may further include metadata, such as the pod type metadata (a.k.a., application hint metadata) described above, as well as PU and memory resource requests and PU and memory limits.

[0030] After receiving the deploy pod request, agent 218 allocates resources to the container. For instance, agent 218 assigns the container to one or more of the PU cores of PU 212. After allocating the resources to the container, agent 218 provides to EMF 220 a container deployment request (CDR), which includes container deployment information (CDI). In one embodiment, the CDI includes the container image identifier and a PU core identifier for each PU core to which the container is assigned. The CDI also indicates a QoS class for the container (e.g., Guaranteed, Burstable, or Best Effort). In some embodiments, the CDI also includes the pod type metadata.

[0031] After receiving the CDR from agent 218, EMF 220 perform and energy savings process by potentially configuring PU 212 based on the CDI. For example, based on the CDI, EMF 220 may configure one or more of the PU cores identified by the CDI and / or uncore component 214. In one embodiment, after receiving the CDR, EMF 220 determines, based on the CDI, the QoS class for the container and decides how to configure PU 212 based on the determined QoS class, the current configuration of PU 212, and capability information associated with PU 212 (e.g., max and min operating frequencies for the various components of PU 212). For instance, EMF 220 may decide that for the burstable and best effort class, EMF 220 need not do nothing because the current configuration of PU 212 is suitable for a burstable or best effort container. On the other hand, if the current configuration of PU 212 is suitable for a burstable orbest effort containers and the determined QoS class is Guaranteed QoS, then EMF 220 configures the PU cores to which the container is assigned to be high-performance cores (e.g., the core frequency is set to the PU core’s max value).

[0032] In an embodiment in which the CDI includes the pod type information, EMF 202 may decide how to configure PU 212 based on the pod type information (or base on the pod type information, the determined QoS class, and capability information). For instance, if the pod type indicates that PU cores should have priority over the uncore component, then EMF sets the identified PU cores to have high performance and may set the uncore component to have low performance. In contrast, if the pod type indicates that the uncore component should have priority over the PU cores, then EMF may set the identified PU cores to have low performance and sets the uncore component to have high performance.

[0033] Table 2 below illustrates an example of pseudo code for implementing the energy savings process performed by EMF 220 in one embodiment.TABLE 2

[0034] After performing the energy savings process, if EMF 220 has decided to reconfigure PU 212, EMF 220, in one embodiment, provides the determined configuration parameters to OS 216 so that OS 216 can reconfigure PU 212. For example, in one embodiment, EMF 220 provides the determined configuration parameters to OS 216 by executing one or more of the echo commands shown in Table 3 below.TABLE 3

[0035] As a specific example, a container with guaranteed QoS class assigned to run on cpu cores 0 and 104 with pod type of “membound” could trigger the PU settings shown in Table 4. In this example, the uncore component (e.g., the interconnect fabric) is prioritized over the PU cores.TABLE 4

[0036] Lastly, as shown in FIG. 3, EMF 220 forwards the CDR to CE 222 so that CE can deploy the container.

[0037] To summarize, in some embodiments, in response to receiving the CDR from agent 218, EMF 229 checks the capabilities of PU 212 and configures PU 212 when possible if needed. Most of the configuration is available via standard Linux OS api and common for most PUs, while others, uncore frequency as an example, is special for each PU vendor and need to be adapted for each PU. If EMF 220 is not able to configure PU 212, the CDR is forwarded to the CE (e.g., containerd) without any infrastructure modifications.

[0038] To further enhance the power efficiency (e.g., for telecom grade services), EMF 220 may configure PU 212 to use a fast transition mechanism called micro-sleep to quickly enter and exit power states. To enable the same characteristics for control plane traffic where traffic is based upon host OS events, a micro-sleep function is used when host OS is idle. This enables efficient power management without impacting the host OS and application characteristics. For example, a user plane application may configure PU 212 to use a fast transition mechanism called micro-sleep to quickly enter and exit power states in user space without any interaction with the host OS. On an Intel platform this is called UMWAIT. This enables efficient power management without impacting the host OS and application characteristics.

[0039] The amount of time in micro-sleep state (user plane) and c-state (control plane) determines the service computer utilization and can be measured via hardware counters. As the uncore frequency is a shared resource for all containers, EMF 220 determines whether all guaranteed containers have enough performance headroom, and, if so, EMF 220 may scale down the uncore frequency, otherwise it does not perform the scale down. A performance headroom could be average core utilization over the last measurements period or number of high- performance cores in micro-sleep state or in an enhanced halt state (e.g., C1E states) used by control plane. After X repetition of the power reduction algorithm, the system enters the lowest possible energy consumption.

[0040] In another embodiment, EMF 220 is configured to detect traffic bursts associated with a container having the Guaranteed QoS class, and is further configured such that in response to detecting such a traffic burst, EMF 220 sets the uncore frequency to it maximum possible setting. The system immediately enters maximum performance.

[0041] Configuring Agent 218 to communicate with EMF 220

[0042] EMF 220 uses a socket interface to receive messages from other processes running on node 200. In one embodiment, EMF 220 uses a particular socket (e.g., socket file or TCP socket) to receive messages from other processes running on node 200 (e.g., agent 218). In such an embodiment, agent 218 is configured to provide the CDR to EMF 220 by setting an endpoint configuration parameter for the agent (e.g., if agent 218 is a kublet, then the endpoint configuration parameter is the “container-runtime-endpoinf ’ parameter) equal to a socket identifier for use in identifying the particular socket (e.g., UNIX: / / / run / emf / emfd.sock). EMF 220 can therefore be introduced without any changes in Kubemetes and added / removed by restarting the kubelet. If EMF 220 is not present, the configuration endpoint parameter is removed and Kubernetes work as before.

[0043] FIG. 4 is a flow chart illustrating a process 400, according to an embodiment, for managing energy consumption of node 200. Process 400 may be performed by EMF 220 and begin in step s402. Step s402 comprises receiving, from agent 218, container deployment information (CDI) for use in deploying on the node at least a first container (e.g., container cl) assigned to at least a first PU core 231. Step s404 comprises, in response to receiving the CDI from the agent, configuring (s404) the first PU core and / or the uncore component based on the CDI. Step s406 comprises providing the CDI to the container engine (CE) 222.

[0044] In some embodiments, the CDI comprises first quality-of-service (QoS) class information indicating a QoS class for the first container, and the process comprises configuring the first PU core and / or the uncore component based on the QoS class information. In some embodiments, the process further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component, and the first PU core and / or the uncore component are configured based on the QoS class information and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

[0045] In some embodiments, the CDI further comprises metadata (a.k.a., “application hint”), and the process comprises configuring the first PU core and / or the uncore component based on the metadata.

[0046] In some embodiments, the process further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of theuncore component, and the first PU core and / or the uncore component are configured based on the metadata and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

[0047] In some embodiments, the process comprises configuring the first PU core and / or the uncore component based on the metadata and the Qos class information.

[0048] In some embodiments, the process comprises configuring the first PU core and / or the uncore component based on the metadata, the Qos class information, and the capability information.

[0049] In some embodiments, the CDI further comprises a first PU core identifier identifying the first PU core, and the process comprises configuring the first PU core as a result of determining that the CDI comprise the first PU core identifier.

[0050] In some embodiments, the PU further comprise a second PU core, the container is also assigned to a second PU core, the CDI further comprises a second PU core identifier identifying the second PU core, and the process further comprises configuring the second PU core based on the CDI as a result of determining that the CDI further comprise the second PU core identifier.

[0051] In some embodiments, receiving the CDI comprises receiving from the agent a container deployment request comprising the CDI.

[0052] In some embodiments, the receiving, configuring, and providing steps are performed by an energy management function, EMF, running on the node, the EMF is not a container runtime, the container engine is a container runtime, and the process further comprises configuring the agent to provide the container deployment request to the EMF (i.e., configure the agent to use the EMF as the agent’s container runtime).

[0053] In some embodiments, the EMF is using a particular socket (e.g., socket file or TCP socket) to receive messages from the agent, and configuring the agent to provide the container deployment request to the EMF comprises setting an endpoint configuration parameter for the agent (e.g., the container-runtime-endpoint parameter) equal to a socket identifier for use in identifying the particular socket (e.g., UNIX: / / / run / emf / emfd.sock).

[0054] In some embodiments, the process further comprises storing mapping information (e.g., a table) that maps: a first QoS class (e.g., Guaranteed QoS) to a first set of configuration parameter values; a second QoS class (e.g., Burstable) to a second set of configuration parameter values; and a third QoS class (e.g., Best Effort) to a third set of configuration parameter values, the CDI comprises QoS class information that indicates the first QoS class, and configuring the first PU core based on CDI information comprises: using the QoS class information to retrieve the first set of configuration parameter values; and after retrieving the first set of configuration parameter values, configuring the first PU core using the first set of configuration parameters values.

[0055] In some embodiments, the CDI further comprises a container image identifier for the container, and the process further comprises the container engine using the container image identifier to retrieve a container image identified by the container image identifier and deploy the container image.

[0056] In some embodiments, configuring the first PU core and / or the uncore component comprises providing one or more configuration parameters to an operating sytem, OS, running on the node, wherein the OS is operable to configure the first PU core and / or the uncore component.

[0057] In some embodiments, the agent is a process running on the node.

[0058] In some embodiments, the agent is a process running on a control plane node that is separate from the node.

[0059] FIG. 5 is a flow chart illustrating a process 500, according to an embodiment, for managing energy consumption of node 200. Process 500 may be performed by EMF 220 and begin in step s502. Step s502 comprises receiving, from agent 218, a container deployment request (CDR) comprising container deployment information (CDI) for use in deploying on the node at least a first container (e.g., container cl) assigned to at least a first PU core 231.

[0060] Step s504 comprises, in response to receiving the CDI from the agent, determining the PU cores to which the container is assigned and determining the container’s QoS class.

[0061] Step s506 comprises configuring the determined PU core(s) based on the determined QoS class.

[0062] Step s508 comprises providing the CDR to the container engine (CE) 222.

[0063] Step s510 comprises monitoring the system and reconfiguring the PU cores as needed. For instance, as noted above, EMF 220 can be configured to detect traffic bursts associated with a container, determine whether the associated container has a Guaranteed QoS class, and, as a result of detecting the traffic burst for the Guaranteed QoS container, set the uncore frequency to it maximum possible setting.

[0064] FIG. 6 is a block diagram of node 200, according to some embodiments. As shown in FIG. 6, node 200, in addition to comprising PU 212, comprises at least one network interface 648 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 645 and a receiver (Rx) 647 for enabling node 200 to transmit data to and receive data from other nodes connected to network 110 (e.g., an Internet Protocol (IP) network) to which network interface 648 is connected (physically or wirelessly) (e.g., network interface 648 may be coupled to an antenna arrangement comprising one or more antennas for enabling node 200 to wirelessly transmit / receive data); and a storage unit (a.k.a., “data storage system”) 608, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 602 includes a programmable processor, a computer readable storage medium (CRSM) 642 may be provided. CRSM 642 may store a computer program (CP) 643 comprising computer readable instructions (CRI) 644. CRSM 642 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 644 of computer program 643 is configured such that when executed by PC 602, the CRI causes node 200 to perform steps described herein (e.g., steps described herein with reference to the flow charts and / or message flow diagrams). In other embodiments, node 200 may be configured to perform steps described herein without the need for code. That is, for example, PC 602 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0065] Conclusion

[0066] In summary, this disclosure provides an energy management function (EMF) that uses application hints, QoS information, and / or PU capability information to reduce the energy consumption of a node. The energy saving can be used to boost the application peak performance by redirecting energy to the performance critical containers.

[0067] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0068] As used herein transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein “a” means “at least one” or “one or more.”

[0069] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

CLAIMS1. A method (400) for managing energy consumption of a node (200) comprising a processing unit, PU (212), the PU (212) comprising a first PU core (231) and an uncore component (214), the method comprising: receiving (s402), from an agent (218), container deployment information, CDI, for use in deploying on the node at least a first container (cl) assigned to at least the first PU core; in response to receiving the CDI from the agent, configuring (s404) the first PU core and / or the uncore component based on the CDI; and providing (s406) to a container engine, CE, the CDI.

2. The method of claim 1, wherein the CDI comprises first quality-of-service (QoS) class information indicating a QoS class for the first container, and the method comprises configuring the first PU core and / or the uncore component based on the QoS class information.

3. The method of claim 2, wherein the method further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component, and the first PU core and / or the uncore component are configured based on the QoS class information and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

4. The method of claim 1, 2, or 3, wherein the CDI further comprises metadata , and the method comprises configuring the first PU core and / or the uncore component based on the metadata.

5. The method of claim 4 when dependent on claim 1 or 2, whereinthe method further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component, and the first PU core and / or the uncore component are configured based on the metadata and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

6. The method of claim 4 when dependent on claim 2, wherein the method comprises configuring the first PU core and / or the uncore component based on the metadata and the Qos class information.

7. The method of claim 4 when dependent on claim 3, wherein the method comprises configuring the first PU core and / or the uncore component based on the metadata, the Qos class information, and the capability information.

8. The method of any one of claims 1-7, wherein the CDI further comprises a first PU core identifier identifying the first PU core, and the method comprises configuring the first PU core as a result of determining that the CDI comprise the first PU core identifier.

9. The method of claim 8, wherein the PU further comprise a second PU core, the container is also assigned to a second PU core, the CDI further comprises a second PU core identifier identifying the second PU core, and the method further comprises configuring the second PU core based on the CDI as a result of determining that the CDI further comprise the second PU core identifier.

10. The method of any one of claims 1-9, wherein receiving the CDI comprises receiving from the agent a container deployment request comprising the CDI.

11. The method of claim 10, whereinthe receiving, configuring, and providing steps are performed by an energy management function, EMF, running on the node, the EMF is not a container runtime, the container engine is a container runtime, and the method further comprises configuring the agent to provide the container deployment request to the EMF.

12. The method of claim 11, wherein the EMF is using a particular socket to receive messages from the agent, and configuring the agent to provide the container deployment request to the EMF comprises setting an endpoint configuration parameter for the agent equal to a socket identifier for use in identifying the particular socket .

13. The method of claim 2 or 3, wherein the method further comprises storing mapping information that maps: a first QoS class to a first set of configuration parameter values; a second QoS class to a second set of configuration parameter values; and a third QoS class to a third set of configuration parameter values, the CDI comprises QoS class information that indicates the first QoS class, and configuring the first PU core based on CDI information comprises: using the QoS class information to retrieve the first set of configuration parameter values; and after retrieving the first set of configuration parameter values, configuring the first PU core using the first set of configuration parameters values.

14. The method of any one of claims 1-13, wherein the CDI further comprises a container image identifier for the container, and the method further comprises the container engine using the container image identifier to retrieve a container image identified by the container image identifier and deploy the container image.

15. The method of any one of claim 1-14, wherein configuring the first PU core and / or the uncore component comprises providing one or more configuration parameters to an operating sytem, OS, running on the node, wherein the OS is operable to configure the first PU core and / or the uncore component.

16. A computer program (643) comprising instructions (644) which when executed by a processing unit (212) of a node (200) causes the node to perform the method of any one of claims 1-15.

17. A carrier containing the computer program of claim 16, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (642).

18. A node (200) comprising a processing unit, PU (212), the PU comprising a first PU core (231) and an uncore component (214), wherein the node is configured to perform an energy management method (400) comprising: receiving (s402), from an agent (218), container deployment information, CDI, for use in deploying on the node at least a first container (cl) assigned to at least the first PU core; in response to receiving the CDI from the agent, configuring (s404) the first PU core and / or the uncore component based on the CDI; and providing (s406) to a container engine, CE, the CDI.

19. The node of claim 18, wherein the CDI comprises first quality-of-service (QoS) class information indicating a QoS class for the first container, and the method comprises configuring the first PU core and / or the uncore component based on the QoS class information.

20. The node of claim 19, wherein the method further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component, andthe first PU core and / or the uncore component are configured based on the QoS class information and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

21. The node of claim 18, 19, or 20, wherein the CDI further comprises metadata, and the method comprises configuring the first PU core and / or the uncore component based on the metadata.

22. The node of claim 21 when dependent on claim 18 or 19, wherein the method further comprises obtaining capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component, and the first PU core and / or the uncore component are configured based on the metadata and capability information indicating a capability of the first PU core and / or indicating a capability of the uncore component.

23. The node of claim 21 when dependent on claim 19, wherein the method comprises configuring the first PU core and / or the uncore component based on the metadata and the Qos class information.

24. The node of claim 21 when dependent on claim 20, wherein the method comprises configuring the first PU core and / or the uncore component based on the metadata, the Qos class information, and the capability information.

25. The node of any one of claims 18-24, wherein the CDI further comprises a first PU core identifier identifying the first PU core, and the method comprises configuring the first PU core as a result of determining that the CDI comprise the first PU core identifier.

26. The node of claim 25, wherein the PU further comprise a second PU core,the container is also assigned to a second PU core, the CDI further comprises a second PU core identifier identifying the second PU core, and the method further comprises configuring the second PU core based on the CDI as a result of determining that the CDI further comprise the second PU core identifier.

27. The node of any one of claims 18-26, wherein receiving the CDI comprises receiving from the agent a container deployment request comprising the CDI.

28. The node of claim 27, wherein the receiving, configuring, and providing steps are performed by an energy management function, EMF, running on the node, the EMF is not a container runtime, the container engine is a container runtime, and the method further comprises configuring the agent to provide the container deployment request to the EMF.

29. The node of claim 28, wherein the EMF is using a particular socket to receive messages from the agent, and configuring the agent to provide the container deployment request to the EMF comprises setting an endpoint configuration parameter for the agent equal to a socket identifier for use in identifying the particular socket.

30. The node of claim 19 or 20, wherein the method further comprises storing mapping information that maps: a first QoS class to a first set of configuration parameter values, and a second QoS class to a second set of configuration parameter values; and the CDI comprises QoS class information that indicates the first QoS class, and configuring the first PU core based on CDI information comprises: using the QoS class information to retrieve the first set of configuration parameter values; andafter retrieving the first set of configuration parameter values, configuring the first PU core using the first set of configuration parameters values.

31. The node of any one of claims 18-30, wherein the CDI further comprises a container image identifier for the container, and the method further comprises the container engine using the container image identifier to retrieve a container image identified by the container image identifier and deploy the container image.

32. The node of any one of claim 18-31, wherein configuring the first PU core and / or the uncore component comprises providing one or more configuration parameters to an operating sytem, OS, running on the node, wherein the OS is operable to configure the first PU core and / or the uncore component.

33. The node of any one of claims 18-32, wherein the agent is a process running on the node.

34. The node of any one of claims 18-32, wherein the agent is a process running on a control plane node that is separate from the node.

Images