Configuring Hardware Multithreading in Containers

Abstract

As part of a container initialization procedure that configures an operating system running on a computer system for container execution and configures a first container for execution on the operating system, a maximum number of hardware threads per processor core within a set of cores of the computer system is enabled. An execution core is selected from the set of available cores of the set of cores. The selected execution core is configured with a number of threads per core to be used during execution of the first container, the number of threads per core being specified for the container initialization procedure by a first simultaneous multithreading (SMT) parameter. The first container is executed using the configured execution core, and the execution virtualizes the operating system.

Description

[Technical field]

[0001] The present invention relates generally to a method, system, and computer program product for configuring hardware multithreading. More particularly, the present invention relates to a method, system, and computer program product for configuring hardware multithreading in a container. [Background technology]

[0002] A virtual machine (VM) virtualizes or emulates a physical computer system. VMs are managed by a hypervisor, which performs resource virtualization and isolates VMs from each other. Each virtual machine contains a guest operating system (OS), a virtual copy of the hardware the OS needs to run, and at least one application with associated libraries and dependencies that run on the guest OS.

[0003] Containers are similar to VMs, but instead of virtualizing a physical computer system, containers virtualize an operating system. The operating system can run on a VM or on a physical computer. Multiple containers can run on the same machine, sharing the OS kernel with other containers, each of which runs as a separate processor in user space. Each individual container contains only the application and its libraries and dependencies.

[0004] Because containers do not contain their own OS, they are smaller and more quickly deployed than VMs. Additionally, because communication between containers requires less overhead than communication between VMs, containers also enable microservices architectures, where application components rather than complete applications are deployed and scaled. As a result, application components within an application can be isolated from each other, and if a single component is under load, additional instances of the component can be deployed rather than the entire application.

[0005] There are several different methods available for specifying one or more configuration values ​​that affect the configuration and behavior of a container. One implementation of a container includes a command line interface (CLI) that is used to specify the container configuration values. Another implementation of a container includes an application program interface (API) that is used by another program, such as an orchestration framework, to specify the container configuration values. Container configuration values ​​can also be specified in a platform configuration value that encapsulates the container, including the container image, a self-contained static set of files including application component executables, system libraries, system tools, and anything necessary to run the image as a container. Some container images apply to a specific platform or architecture. Other container images have multi-platform or multi-architecture capabilities and can include settings specific to each platform or architecture supported. Container configuration values ​​and preferences can also be specified in a container registry that stores one or more container images for deployment.

[0006] In computer systems management, orchestration is the automated configuration, coordination, and management of computer systems and software. Orchestration typically automates a process or workflow that involves many steps between multiple heterogeneous systems. An orchestration framework is a software tool that performs orchestration. One function of an orchestration framework is to compose and deliver containers, although containers can be compose and delivered without the use of an orchestration framework. Kubernetes® is a non-limiting example of an orchestration framework. Other orchestration frameworks are currently available. (Kubernetes is a registered trademark of the Linux Foundation in the U.S. and other countries.)

[0007] Hardware multithreading is the ability of a computer processor, or a single processor core within a multicore processor, to execute multiple threads of an application or application component in parallel. Summary of the Invention

[0008] Exemplary embodiments provide methods, systems, and computer program products. One embodiment includes a method of enabling a maximum number of hardware threads per core of a set of processor cores (cores) of a computer system as part of a container initialization procedure, where the container initialization procedure configures an operating system executing on the computer system for container execution and configures a first container for execution on the operating system. One embodiment selects an execution core from a set of available cores of the set of cores. One embodiment configures, on the selected execution core, a number of threads per core to be used during execution of the first container, the number of threads per core specified by a first simultaneous multithreading (SMT) parameter for the container initialization procedure. One embodiment executes the first container using the configured execution core, where the execution virtualizes the operating system.

[0009] One embodiment includes a computer usable program product that includes one or more computer readable storage devices and program instructions stored in at least one of the one or more storage devices.

[0010] One embodiment includes a computer system including one or more processors, one or more computer readable memories, one or more computer readable storage devices, and program instructions stored in at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories.

[0011] The particular novel features which are believed to be characteristic of the invention are set forth in the appended claims, but the invention itself, together with its preferred modes of use, further objects and advantages, will best be understood by reference to the following detailed description of illustrative embodiments read in conjunction with the accompanying drawings, in which: [Brief description of the drawings]

[0012] [Figure 1] 1 is a block diagram illustrating a network of data processing systems in which illustrative embodiments may be implemented; [Diagram 2] 1 is a block diagram illustrating a data processing system in which the illustrative embodiments may be implemented; [Diagram 3] FIG. 2 is a block diagram illustrating an example configuration for configuring hardware multithreading in a container, according to an example embodiment. [Figure 4] FIG. 2 is a block diagram illustrating an example configuration for configuring hardware multithreading in a container, according to an example embodiment. [Diagram 5] FIG. 1 illustrates an example of configuring hardware multithreading in a container, according to an example embodiment. [Figure 6] FIG. 11 illustrates a continuation of an example of configuring hardware multithreading in a container, according to an example embodiment. [Figure 7] FIG. 11 illustrates a continuation of an example of configuring hardware multithreading in a container, according to an example embodiment. [Figure 8] FIG. 1 illustrates an example of configuring hardware multithreading in a container, according to an example embodiment. [Figure 9] FIG. 11 illustrates a continuation of an example of configuring hardware multithreading in a container, according to an example embodiment. [Figure 10] 1 is a flowchart illustrating an example process for configuring hardware multithreading in a container, according to an example embodiment. [Figure 11]FIG. 1 illustrates a cloud computing environment according to one embodiment of the present invention. [Figure 12] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] The illustrative embodiments recognize that not all processing workloads benefit from running using multithreading. Also, different processing workloads benefit from running using different numbers of threads. Some workloads are latency sensitive and have stringent requirements for average or worst case response times for transactions. For example, workloads such as Voice over IP (VoIP) and streaming video are latency sensitive because they process data in real time. When multiple threads are competing to acquire the same resources, such as cache, system memory and network resources, the increased wait time to acquire the resources also increases the latency. As a result, latency sensitive workloads often benefit from running using only one or two threads even when additional threads are available. Other workloads (e.g. database workloads) process as much data as possible, but often give up processing time while waiting for input / output or other blocking operations, and therefore often benefit from running with as many threads as possible. When a processing workload is implemented as an application within a VM, the application has thread usage settings configured within the guest OS, thereby allowing tuning of thread usage to meet the requirements of a particular application.

[0014] The illustrative embodiments also recognize that, unlike VMs, containers inherit their thread usage configuration from the operating system on which they are virtualized. Thus, all containers running in a VM or on a physical server without a VM have the same thread usage settings. However, if all containers use the same thread usage settings, the settings are unlikely to provide adequate performance for the requirements of a particular workload. For example, an application may include two components, one performing database operations (and thus requiring execution with as much parallelism as possible to maximize throughput) and another processing real-time video (and thus executing using only one or two threads to minimize latency). Setting thread usage to as many threads as possible may result in too much latency for the image processing container, single-threaded execution may make the database operation container unnecessarily slow, and a compromise setting may result in unacceptable performance for both containers. Thus, the illustrative embodiments recognize that the number of threads used in container execution needs to be tuned on a per-container basis.

[0015] The illustrative embodiments recognize that currently available tools or solutions do not address or provide an adequate solution to the above needs. The illustrative embodiments used to describe the present invention generally address and solve the above-mentioned problems and other problems related to configuring hardware multithreading in containers.

[0016] An embodiment may be implemented as a software application. An application implementing an embodiment may be configured as a modified version of an existing container configuration system, as a separate application that operates in conjunction with an existing container configuration system, as a standalone application, or any combination thereof.

[0017] In particular, some example embodiments provide a method for enabling a maximum number of hardware threads per processor core as part of an operating system initialization procedure for a container host and a container initialization procedure, selecting one or more execution cores, configuring the number of threads per core within the execution cores, and using the configured execution cores for execution of the initialized container.

[0018] The container initialization procedure prepares the operating system to run the container and prepares the container for execution virtualizing the operating system. As part of the container initialization procedure, one embodiment receives a set of container execution parameters. The container execution parameters specified in the container image represent the application developer's understanding of the application components intended to run in the container and the optimal execution settings for that particular application component.

[0019] In one embodiment, the set of container execution parameters includes a simultaneous multithreading (SMT) parameter that specifies how many threads per core are used to execute the container. For example, a container that executes at SMT1 uses cores that have only one thread enabled on each core. As another example, a container that executes at SMT8 uses cores that have eight threads enabled on each core. In another embodiment, the set of container execution parameters includes a container core parameter that specifies the number of cores that are used to execute the container that is initialized. In another embodiment, the set of container execution parameters includes a parameter that specifies the total number of threads that are used to execute the container that is initialized, the embodiment determining the container core parameter from the SMT parameter and the total number of threads. In another embodiment, the set of container execution parameters includes a shareability parameter that specifies whether the threads that are used to execute the container are shareable with another container. In another embodiment, the set of container execution parameters includes other or additional parameters.

[0020] In an embodiment, the container execution parameters are specified via a CPI or API or within metadata associated with the container image. A container image that applies to a particular platform or architecture includes a set of container execution parameters appropriate for that platform or architecture. A container image with multi-platform or multi-architecture capabilities often includes multiple sets of container execution parameters, each set configuring the container for execution on a different supported platform or architecture. Another embodiment receives a set of preferences from a container registry or another source and determines a corresponding set of container execution parameters. In one embodiment, the set of preferences is actually a set of requirements, i.e., configuration values ​​that the container must implement. One non-limiting example of a set of requirements is that the container must run with the maximum possible number of threads per core, without specifying a specific number of threads per core. Structuring the requirements in this manner avoids the need to specify a specific number of threads per core for each different processor architecture, since different architectures can have different numbers of threads per core. In another embodiment, the set of preferences is not a hard set of requirements, but includes configuration values ​​that the container must try its best to implement. One non-limiting example of a set of preferences is that a container should run with one exclusive thread per core when possible, but one shareable thread per core is acceptable when exclusivity is not available. In one embodiment, the determined set of container execution parameters overrides parameters specified in the container image.

[0021] As part of the container initialization procedure, an embodiment prepares the operating system for use with the container by enabling the maximum number of hardware threads per processor core in the computer system on which the container runs. This enablement overrides any default, previous, or inherited thread settings. An embodiment performs this enablement using any currently available technique. For example, the SMTCTL command in the AIX operating system and the ppc64_cpu command in the Linux operating system on IBM Power systems may be used to perform the enablement. (AIX and IBM are registered trademarks of International Business Machines Corporation in the U.S. and other countries. Linux is a registered trademark of Linus Torvalds in the U.S. and other countries.)

[0022] One embodiment uses any currently available technique to determine which processor cores are available to run the container being initialized. For example, the virsh vcpupin command provided by the Red Hat Linux operating system provides core availability data. (Red Hat is a registered trademark of Red Hat Inc. in the United States and other countries.) One embodiment selects from the available cores a number of cores specified by the container cores parameter. The container will be initialized and run on the selected cores.

[0023] An embodiment configures the selected cores to run using the number of threads per core specified by the SMT parameters. Since the maximum number of hardware threads per processor core was previously enabled, an embodiment's configuration disables as many threads as necessary to get the number of threads per core specified by the SMT parameters. For example, consider a processor with 8 threads per core. To run a container at SMT8, all 8 threads are already enabled, so an embodiment does not disable any threads on each core used. To run a container at SMT4, an embodiment disables 4 threads on each core used. To run a container at SMT1, an embodiment disables 7 threads on each core used.

[0024] An embodiment configures the selected cores to run according to the shareability parameters. If the shareability parameters are not specified, an embodiment applies a default setting of either shareable or exclusive. If the selected cores are configured for exclusive use, an embodiment runs the container using the selected configured cores and does not allow other containers to use those cores while this first container is running. If the selected cores are configured for shareable use, an embodiment runs the container using the selected configured cores. This embodiment also allows a second container to run using the selected cores and threads in those cores, with SMT parameters equal to the SMT parameters of the first container. Note that both containers sharing a core use only enabled threads, and disabled threads remain disabled for both containers.

[0025] The methods for configuring hardware multithreading in containers described herein are not available in currently available methods in the art of container configuration and execution related endeavors. The methods of one embodiment described herein, when implemented to run in a device or data processing system, include a substantial advance in the functionality of the device or data processing system in enabling a maximum number of hardware threads per processor core as part of a container initialization procedure, selecting one or more execution cores, configuring the number of threads per core in the execution cores, and using the execution cores configured to execute the initialized container.

[0026] The illustrative embodiments are described, by way of example only, with reference to particular types of processors, cores, threads, containers, parameters, preferences, adjustments, devices, data processing systems, environments, components, and applications. The specific realization of these and other similar artifacts is not intended as a limitation on the invention. Any suitable realization of these and other similar artifacts may be selected within the scope of the illustrative embodiments.

[0027] Additionally, the exemplary embodiments may be implemented with any type of data, data source, or access to a data source via a data network. Any type of data storage device may provide data to the embodiments of the present invention locally at a data processing system or via a data network within the scope of the present invention. Where an embodiment is described with a mobile device, any type of data storage device suitable for use with the mobile device may provide data to such embodiments locally at the mobile device or via a data network within the scope of the exemplary embodiments.

[0028] The exemplary embodiments are described using specific code, designs, architectures, protocols, layouts, diagrams, and tools as examples only and are not limitations on the exemplary embodiments. Also, the exemplary embodiments are described using specific software, tools, and data processing environments in some cases as examples only for clarity of explanation. The exemplary embodiments may be used with other equivalent or similar purpose structures, systems, applications, or architectures. For example, other equivalent mobile devices, structures, systems, applications, or architectures therefor may be used with such embodiments of the present invention within the scope of the present invention. An exemplary embodiment may be implemented in hardware, software, or a combination thereof.

[0029] The examples in this disclosure are used for clarity of explanation only and are not limitations on the example embodiments. Additional data, operations, actions, tasks, activities and operations are conceivable from this disclosure and are contemplated within the scope of the example embodiments.

[0030] Any advantages listed herein are merely examples and are not intended as limitations on example embodiments. Additional or different advantages may be realized depending on the particular example embodiment. Also, a particular example embodiment may have some, all, or none of the advantages listed above.

[0031] Although this disclosure includes a detailed description of a cloud computing environment, it should be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0032] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0033] Its features are as follows.

[0034] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0035] Broad network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin-client or thick-client platforms (e.g., cell phones, laptops, and PDAs).

[0036] Resource Pooling: To serve multiple consumers using a multi-tenant model, a provider's computing resources are pooled, with different physical and virtual resources dynamically allocated and reallocated depending on demand. Consumers generally have no control or knowledge of the exact location of the resources provided, but there is a sense of location independence in that it may be possible to specify a higher level of abstraction of location (e.g., country, state, or data center).

[0037] Rapid Elasticity: With rapid elasticity, you can quickly scale out, in some cases automatically provisioning capabilities, and quickly release capabilities to quickly scale in. To the consumer, the capabilities available for provisioning often seem infinite, and you can buy as much as you want, at any time.

[0038] Metered Services: The cloud system automatically controls and optimizes resource utilization by utilizing metering capabilities at some level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, giving both providers and consumers transparency of the services utilized.

[0039] The service model is as follows:

[0040] Software as a Service (SaaS): The functionality provided to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer has no management or control over the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0041] Platform as a Service (PaaS): The capability offered to the consumer is the deployment of consumer-created or acquired applications, written using programming languages ​​and tools supported by the provider, on a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application hosting environment configuration.

[0042] Infrastructure as a Service (IaaS): The capability offered to the consumer is to provision processing, storage, network and other basic computing resources onto which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

[0043] The deployment model is as follows:

[0044] Private Cloud: This cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0045] Community Cloud: This cloud infrastructure is shared by several organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance concerns). It can be managed by the organization or a third party and can reside on-premise or off-premise.

[0046] Public Cloud: This cloud infrastructure is available to the public or large industry organizations and is owned by an organization that sells cloud services.

[0047] Hybrid Cloud: This cloud infrastructure is a composite of two or more clouds (private, community or public) that remain their own entity but are joined by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0048] Cloud computing environments are service-oriented with a focus on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0049] With reference to the drawings, and in particular with reference to Figures 1 and 2, these figures are exemplary diagrams of data processing environments in which example embodiments may be implemented. Figures 1 and 2 are only examples and are not intended to assert or imply any limitation with respect to the environments in which different embodiments may be implemented. Particular implementations may make many modifications to the depicted environments based on the following description.

[0050] 1 illustrates a block diagram of a network of data processing systems in which the illustrative embodiments may be implemented. Data processing environment 100 is a network of computers in which the illustrative embodiments may be implemented. Data processing environment 100 includes network 102. Network 102 is the medium used to provide communications links between various devices and computers connected to each other within data processing environment 100. Network 102 may include connections, such as wires, wireless communication links, or fiber optic cables.

[0051] Client or server are merely examples of roles for particular data processing systems connected to network 102 and are not intended to exclude other configurations or roles of these data processing systems. Server 104 and server 106 are coupled to network 102 along with storage unit 108. Software applications may be executed on any computer in data processing environment 100. Clients 110, 112 and 114 are also coupled to network 102. A data processing system, such as server 104 or 106 or client 110, 112 or 114, may contain data and may have software applications or software tools executed thereon.

[0052] By way of example only and without implying any limitation to such an architecture, FIG. 1 illustrates certain components that may be used in an exemplary implementation of one embodiment. For example, servers 104 and 106 and clients 110, 112, 114 are illustrated as servers and clients by way of example only and without implying any limitation to a client-server architecture. As another example, one embodiment may be distributed across several data processing systems and data networks as illustrated, although other embodiments may be implemented on a single data processing system within the scope of the exemplary embodiment. Data processing systems 104, 106, 110, 112, and 114 also represent exemplary nodes in a cluster, partitions, and other configurations suitable for implementing one embodiment.

[0053] Device 132 is an example of a device as described herein. For example, device 132 may take the form of a smartphone, a tablet computer, a laptop computer, a client 110 in fixed or portable form, a wearable computing device, or any other suitable device. Any software application described as executing in another data processing system of FIG. 1 may be configured to execute in device 132 in a similar manner. Any data or information stored or generated in another data processing system of FIG. 1 may be configured to be stored or generated in device 132 in a similar manner.

[0054] An application 105 implements one embodiment described herein. The application 105 runs on any of the servers 104 and 106, the clients 110, 112 and 114, and the device 132.

[0055] Servers 104 and 106, storage unit 108, clients 110, 112 and 114, and device 132 can be coupled to network 102 using wired connections, wireless communication protocols, or other suitable data connections. Clients 110, 112 and 114 may be, for example, personal computers or network computers.

[0056] In the illustrated embodiment, server 104 may provide data such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 may be clients to server 104 in this embodiment. Clients 110, 112, 114, or any combination thereof, may include their own data, boot files, operating system images, and applications. Data processing environment 100 may include additional servers, clients, and other devices not shown.

[0057] In the depicted example, data processing environment 100 may be the Internet. Network 102 may represent a collection of networks and gateways that use Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols to communicate with one another. At the heart of the Internet is a backbone of data communication links between major nodes or host computers, including thousands of commercial, government, educational and other computer systems that route data and messages. Of course, data processing environment 100 may also be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for the different illustrative embodiments.

[0058] The data processing environment 100 can be used to implement, among other uses, a client-server environment in which the illustrative embodiments can be implemented. A client-server environment allows software applications and data to be distributed across a network such that the applications function using interconnections between client and server data processing systems. The data processing environment 100 may also employ a service-oriented architecture in which interoperable software components distributed across a network can be packaged together as a coherent business application. The data processing environment 100 may take the form of a cloud and employ a cloud computing model of service delivery to enable convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider.

[0059] Referring now to Figure 2, a block diagram of a data processing system in which the illustrative embodiments may be implemented is shown. Data processing system 200 is an example of a computer, such as servers 104 and 106 or clients 110, 112, and 114 in Figure 1, or another type of device in which computer usable program code or instructions implementing processes may be located for the illustrative embodiments.

[0060] Data processing system 200 also represents a data processing system or configuration within a data processing system, such as data processing system 132 of FIG. 1, in which computer usable program code or instructions implementing the processes of the illustrative embodiments may be located. Data processing system 200 is described as a computer by way of example only, and is not limited to being a computer. Implementations in the form of other devices, such as device 132 of FIG. 1, may modify data processing system 200, such as by adding a touch interface, and may omit certain illustrated components from data processing system 200 without departing from the general description of the operation and functionality of data processing system 200 as described herein.

[0061] In the illustrated embodiment, data processing system 200 employs a hub architecture including a north bridge and memory controller hub (NB / MCH) 202 and a south bridge and input / output (I / O) controller hub (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are coupled to north bridge and memory controller hub (NB / MCH) 202. Processing unit 206 may include one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. In a particular implementation, graphics processor 210 may be coupled to NB / MCH 202 via an accelerated graphics port (AGP).

[0062] In the illustrated embodiment, a local area network (LAN) adapter 212 is coupled to the south bridge and I / O controller hub (SB / ICH) 204. An audio adapter 216, a keyboard and mouse adapter 220, a modem 222, a read only memory (ROM) 224, a universal serial bus (USB) and other ports 232, and PCI / PCIe devices 234 are coupled to the south bridge and I / O controller hub 204 via a bus 238. A hard disk drive (HDD) or solid state drive (SSD) 226 and a CD-ROM 230 are coupled to the south bridge and I / O controller hub 204 via a bus 240. The PCI / PCIe devices 234 may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller and PCIe does not. ROM 224 may be, for example, a flash binary input / output system (BIOS). Hard disk drive 226 and CD-ROM 230 may use, for example, an Integrated Drive Electronics (IDE), Serial Advanced Technology Attachment (SATA) interface, or variants such as external SATA (eSATA) and micro SATA (mSATA). A super I / O (SIO) device 236 may be coupled to South Bridge and I / O Controller Hub (SB / ICH) 204 via bus 238.

[0063] Memory such as main memory 208, ROM 224 or flash memory (not shown) are some examples of computer usable storage devices. Hard disk drives or solid state drives 226, CD-ROM 230 and other similarly usable devices are some examples of computer usable storage devices that include computer usable storage media.

[0064] An operating system runs on the processing unit 206. The operating system coordinates and provides control for various components within the data processing system 200 of FIG. 2. The operating system may be a commercially available operating system for any type of computing platform, including but not limited to server systems, personal computers, and mobile devices. An object-oriented or other type of programming system may operate in conjunction with the operating system to allow calls to be made to the operating system from programs or applications running on the data processing system 200.

[0065] Instructions for an operating system, an object oriented programming system, and applications or programs, such as application 105 of Figure 1, are located on a storage device, such as in the form of code 226A on hard disk drive 226, and loadable into at least one of the one or more memories, such as main memory 208, for execution by processing unit 206. The processes of the illustrative embodiments are executable by processing unit 206 using computer-implemented instructions, which may be located in a memory, such as main memory 208, read-only memory 224, or one or more peripheral devices.

[0066] Also, in one example, the code 226A may be downloaded over the network 201A from a remote system 201B where similar code 201C is stored in a storage device 201D. In another example, the code 226A may be downloaded over the network 201A to a remote system 201B where the downloaded code 201C is stored in a storage device 201D.

[0067] The hardware in Figures 1 and 2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be used in addition to or in place of the hardware depicted in Figures 1 and 2. Additionally, the processes of the illustrative embodiments may be applied in multiprocessor data processing systems.

[0068] In some example embodiments, data processing system 200 may be a personal digital assistant (PDA) typically configured with flash memory to provide non-volatile memory for storing operating system files and / or user-generated data. The bus system may include one or more buses, such as a system bus, an I / O bus, and a PCI bus. Of course, the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture.

[0069] The communications unit may include one or more devices used to transmit and receive data, such as a modem or network adapter. The memory may be, for example, main memory 208 or a cache, such as a cache found in north bridge and memory controller hub 202. The processing unit may include one or more processors or CPUs.

[0070] 1 and 2 and above-described embodiments are not meant to imply architectural limitations. For example, data processing system 200 may be a tablet computer, a laptop computer, or a telephone device in addition to taking the form of a mobile or wearable device.

[0071] When a computer or data processing system is described as a virtual machine, virtual device, or virtual component, the virtual machine, virtual device, or virtual component operates in the manner of data processing system 200 using virtualized realizations of some or all of the components illustrated in data processing system 200. For example, in a virtual machine, virtual device, or virtual component, processing unit 206 is embodied as a virtualized instance of all or a portion of the number of hardware processing units 206 available to the host data processing system, main memory 208 is embodied as a virtualized instance of all or a portion of main memory 208 that may be available to the host data processing system, and disk 226 is embodied as a virtualized instance of all or a portion of disk 226 that may be available to the host data processing system. The host data processing system in such a case is represented by data processing system 200.

[0072] Referring to Figure 3, a block diagram of an example configuration for configuring hardware multithreading in a container according to an example embodiment is shown. Application 300 is an example of application 105 of Figure 1 and may run on any of servers 104 and 106, clients 110, 112 and 114, or device 132 of Figure 1.

[0073] As part of the container initialization procedure, a container parameter module 310 receives a set of container execution parameters. In one implementation of module 310, the set of container execution parameters includes an SMT parameter that specifies how many threads per core to use to execute the container. In another implementation of module 310, the set of container execution parameters includes a container core parameter that specifies the number of cores to be used to execute the container being initialized. In another implementation of module 310, the set of container execution parameters includes a parameter that specifies the total number of threads to be used to execute the container being initialized, and module 310 determines the container core parameter from the SMT parameter and the total number of threads. In another implementation of module 310, the set of container execution parameters includes a shareability parameter that specifies whether the threads used to execute the container are shareable with another container. In another implementation of module 310, the set of container execution parameters includes other or additional parameters.

[0074] In an implementation of the module 310, the container execution parameters are specified via a CPI or API or in the container image. Another implementation of the module 310 receives a set of preferences from a container registry or another source and determines a corresponding set of container execution parameters. In one implementation of the module 310, the set of preferences is actually a set of requirements, i.e., configuration values ​​that the container must implement. In another implementation of the module 310, the set of preferences is not a hard set of requirements, but includes configuration values ​​that the container must do its best to implement. In one implementation of the module 310, the determined set of container execution parameters overrides the parameters specified in the container image.

[0075] As part of the container initialization procedure, one embodiment prepares the operating system for use with the container by enabling the maximum number of hardware threads per processor core in the computer system that will run the container, overriding any default or previous thread setting values ​​or thread setting values ​​that may have been inherited from the VM.

[0076] The module 320 determines which processor cores are available to run the container to be initialized. The module 320 selects from the available cores a number of cores specified by the container cores parameter. The container, once initialized, will run on the selected cores.

[0077] Module 320 configures the selected core to run using the number of threads per core specified by the SMT parameters, and to accomplish this configuration, since the maximum number of hardware threads per processor core was previously enabled, module 320 disables a number of threads necessary to achieve the number of threads per core specified by the SMT parameters.

[0078] Module 320 configures the selected cores to run according to the sharable parameters. If the sharable parameters are not specified, module 320 applies a default setting of either sharable or exclusive. If the selected cores are configured for exclusive use, module 320 executes the container using the selected configured cores and does not allow other containers to use those cores while the first container is running. If the selected cores are configured for sharable use, module 320 executes the container using the selected configured cores and allows a second container with equal SMT parameters to run using the selected cores and threads in those cores. Note that both containers sharing a core use only enabled threads and disabled threads remain disabled for both containers.

[0079] Referring now to Figure 4, a block diagram of an example configuration for configuring hardware multithreading in a container according to one example embodiment is shown, which illustrates module 320 of Figure 3 in greater detail.

[0080] As part of the container initialization procedure, the core selection module 410 enables the maximum number of hardware threads per processor core in the computer system that runs the container, overriding any default or previous thread setting values, or any thread setting values ​​that may have been inherited from the VM.

[0081] A thread configuration module 420 determines which processor cores are available to execute the container being initialized. From among the available cores, module 420 selects a number of cores specified by the container core parameters. The container will be executed on the selected cores once it is initialized. Module 420 configures the selected cores to execute using a number of threads per core specified by the SMT parameters and disables a number of threads necessary to obtain the number of threads per core specified by the SMT parameters.

[0082] A shareability module 430 configures the selected cores to execute according to the shareability parameters. If the shareability parameters are not set, the module 430 applies a default setting of either shareable or exclusive. If the selected cores are configured for exclusive use, the module 430 executes the container using the selected configured cores and does not allow other containers to use those cores while the first container is executing. If the selected cores are configured for shareable use, the module 430 executes the container using the selected configured cores and allows a second container having SMT parameters equal to the SMT parameters of the first container to execute using the selected cores and threads within those cores.

[0083] 5, an example of configuring hardware multithreading in a container according to one example embodiment is shown, which may be performed using application 300 of FIG.

[0084] As shown, processor 502 includes cores 510 and 520. Processor 502 has an architecture that uses two threads per core. Core 510 includes threads 512 and 514. Core 520 includes threads 522 and 524. Application 300 enables the maximum number of hardware threads per processor core, here threads 512, 514, 522, and 524.

[0085] Application 300 receives parameters 580 that specify that container 590 being initialized should have exclusive use of one core and two threads per core. Thus, application 300 determines that core 510 is available and selects core 510. Application 300 configures core 510 to run using the number of threads per core specified by the SMT parameters in parameters 580, here two threads. Because two hardware threads per processor core were previously enabled, no threads are disabled. As a result, container 590 runs on core 510 using threads 512 and 514, and no other containers can share core 510.

[0086] 6, which illustrates a continuation of one example of configuring hardware multithreading in a container according to one example embodiment, where the processor 502, the cores 510 and 520, and the threads 512, 514, 522, and 524 are the same as the processor 502, the cores 510 and 520, and the threads 512, 514, 522, and 524 of FIG.

[0087] Application 300 enables the maximum number of hardware threads per processor core, here threads 512, 514, 522, and 524. Application 300 receives parameters 680 that specify that container 690 being initialized is to use two cores and one thread per core exclusively. Thus, application 300 determines that cores 510 and 520 are available and selects both. Application 300 configures cores 510 and 520 to run using the number of threads per core specified by the SMT parameters in parameters 680, here one thread. Because two hardware threads per processor core were previously enabled, application 300 disables one thread per core. As a result, container 690 runs using thread 512 on core 510 and thread 522 on core 510. Threads 514 and 524 are disabled. No other containers can share cores 510 and 520.

[0088] 7, which illustrates a continuation of one example of configuring hardware multithreading in a container according to one example embodiment, where the processor 502, the cores 510 and 520, and the threads 512, 514, 522, and 524 are the same as the processor 502, the cores 510 and 520, and the threads 512, 514, 522, and 524 of FIG.

[0089] Application 300 enables the maximum number of hardware threads per processor core, here threads 512, 514, 522, and 524. Application 300 receives parameters 780 that specify that the container 790 being initialized is to use two cores and one thread per core in common. Thus, application 300 determines that cores 510 and 520 are available and selects both. Application 300 configures cores 510 and 520 to run using the number of threads per core specified by the SMT parameters in parameters 780, here one thread. Because two hardware threads per processor core were previously enabled, application 300 disables one thread per core. As a result, container 790 runs using thread 512 on core 510 and thread 522 on core 520. Threads 514 and 524 are disabled.

[0090] Application 300 also receives parameters 785 that specify that container 795 to be initialized to share two cores, one thread per core. Container 790 is already configured to run using thread 512 on core 510 and thread 522 on core 520, and cores 510 and 520 are shareable. Thus, application 300 configures container 795 to share thread 512 on core 510 and thread 522 on core 520. Threads 514 and 524 remain disabled and are not shared.

[0091] 8, an example of configuring hardware multithreading in a container according to one example embodiment is shown, which may be performed using application 300 of FIG.

[0092] As shown, processor 802 includes cores 810, 820, 830, and 840. Processor 802 has an architecture that uses eight threads per core. Core 810 includes threads 811-818, core 820 includes threads 821-828, core 830 includes threads 831-838, and core 840 includes threads 841-848. Application 300 enables the maximum number of hardware threads per processor core, here threads 811-818, 821-828, 831-838, and 841-848.

[0093] Application 300 receives parameters 880 that specify that container 890 to be initialized has exclusive use of two cores and eight threads per core. Thus, application 300 determines that cores 810 and 820 are available and selects them. Application 300 configures cores 810 and 820 to run using the number of threads per core specified by the SMT parameters in parameters 880, here eight threads. Because eight hardware threads per processor core were previously enabled, no threads are disabled. As a result, container 890 runs using threads 811-818 on core 810 and threads 821-828 on core 810, and no other containers can share cores 810 and 820.

[0094] 9, which illustrates a continuation of one example of configuring hardware multithreading in a container according to one exemplary embodiment. Processor 802, cores 810, 820, 830, and 840, and threads 811-818, 821-828, 831-838, and 841-848 are the same as processor 802, cores 810, 820, 830, and 840, threads 811-818, 821-828, threads 831-838, and threads 841-848 in FIG.

[0095] Application 300 enables the maximum number of hardware threads per processor core, here threads 811-818, 821-828, 831-838, and 841-848. Application 300 receives parameters 980 that specify that container 990 to be initialized is to use two cores and four threads per core. Thus, application 300 determines that cores 810 and 820 are available and selects both. Application 300 configures cores 810 and 820 to run using the number of threads per core specified by the SMT parameters in parameters 980, here four threads. Because eight hardware threads per processor core were previously enabled, application 300 disables four threads per core. As a result, container 990 runs using threads 811-814 on core 810 and threads 821-824 on core 820. Threads 815-818 and 825-828 are disabled.

[0096] Application 300 also receives additional parameters (not shown) that specify that the container 995 being initialized should share two cores with four threads per core. The container 990 is already configured to run using threads 811-814 on core 810 and threads 821-824 on core 820, and cores 810 and 820 are shareable. Thus, application 300 configures container 995 to share threads 811-814 on core 810 and threads 821-824 on core 820. Threads 815-818 and 825-828 remain disabled and are not shared.

[0097] 10, a flow diagram of an example process for configuring hardware multithreading in a container is shown, in accordance with an example embodiment. Process 1000 may be implemented in application 300 of FIG.

[0098] At block 1002, the application enables a maximum number of hardware threads per core of a set of cores of the computer system as part of a container initialization procedure. At block 1004, the application selects at least one execution core from the set of available cores of the set of cores. At block 1006, the application configures the number of threads per core to be used during execution of the container on each selected execution core. At block 1008, the application executes the container using the configured execution core. The application then terminates.

[0099] 11, an exemplary cloud computing environment 50 is illustrated. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, can communicate. The nodes 10 can communicate with each other. The nodes 10 may be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. The types of computing devices 54A-54N shown are intended to be illustrative only, and it is understood that computing node 10 and cloud computing environment 50 may communicate with any type of computerized device via any type of network connection or network addressable connection or combination thereof (e.g., using a web browser).

[0100] Referring to Figure 12, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 11) is shown. It should be understood in advance that the illustrated components, layers and functions are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0101] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0102] The virtualization layer 70 provides an abstraction layer that can instantiate virtual entities such as: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0103] In one embodiment, management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one embodiment, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks and protection of data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to ensure required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provides advance arrangement and procurement for cloud computing resources for anticipated future demand according to SLAs.

[0104] The workload tier 90 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be delivered from this tier include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instructional delivery 93, data analytics processing 94, transaction processing 95, and configuring hardware multithreading in containers 96.

[0105] Thus, computer-implemented methods, systems or apparatus, and computer program products are provided in example embodiments for configuring hardware multithreading and other related features, functions or operations in containers. Where an embodiment, or portions thereof, is described in the context of a type of device, the computer-implemented method, system or apparatus, computer program product, or portions thereof, is adapted or configured for use with an appropriate equivalent incarnation of that type of device.

[0106] Where an embodiment is described as being implemented in an application, distribution of the application in a Software-as-a-Service (SaaS) model is contemplated within the scope of the exemplary embodiments. In a SaaS model, functionality of an application implementing an embodiment is provided to a user by running the application in a cloud infrastructure. A user may access the application through a thin-client interface such as a web browser (e.g., web-based email) or other light-client application using a variety of client devices. A user does not manage or control the underlying cloud infrastructure, including the cloud infrastructure's network, servers, operating systems, or storage. In some cases, a user may not even manage or control the functionality of a SaaS application. In some other cases, a SaaS implementation of an application may allow for limited user-specific possible exceptions to application configuration settings.

[0107] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present invention.

[0108] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge structures in a groove into which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals transmitted over wires.

[0109] The computer readable program instructions described herein may be downloaded from the computer readable storage medium into the respective computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions to a computer readable storage medium within the respective computing / processing device for storage.

[0110] The computer readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or procedural programming languages, such as object oriented programming languages, such as Smalltalk, C++, and the "C" programming language, or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by personalizing the electronic circuitry using state information of the computer readable program instructions to perform aspects of the invention.

[0111] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams that illustrate methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0112] These computer readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to implement a machine such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, form means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable storage medium such that the computer readable storage medium on which the instructions are stored includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0113] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to effect a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0114] The flowcharts and block diagrams in the figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment or portion of instructions, including one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may be performed in a different order than that noted in the figures. For example, two blocks shown in succession may in fact be performed as one step, in parallel, or substantially in parallel, or in a partially or fully overlapped manner in time, or the blocks may be performed in reverse order in some cases, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that executes a combination of dedicated hardware and computer instructions that perform the specified functions or operations.

Claims

1. 1. A computer-implemented method comprising: Configuring an operating system running on a computer system for container execution and enabling a maximum number of hardware threads per core on a set of processor cores (cores) of the computer system as part of a container initialization procedure for configuring a first container for execution on the operating system; selecting an execution core from a set of available cores of the set of cores; configuring a number of threads per core to be used during execution of the first container on the selected execution core, the number of threads per core being specified for the container initialization procedure by a first simultaneous multithreading (SMT) parameter; and executing the first container using the configured execution core, wherein the execution virtualizes the operating system.

2. The computer-implemented method of claim 1 , further comprising determining the first SMT parameter from a container preference setting.

3. 2. The computer-implemented method of claim 1, wherein configuring a number of threads per core in the selected execution core comprises disabling threads in the selected execution core to obtain the number of threads per core specified by the first SMT parameter.

4. The computer-implemented method of claim 1 , wherein a first container core parameter specifies a number of execution cores to be selected from the set of available cores.

5. configuring a selected execution core as shareable; 2. The computer-implemented method of claim 1, further comprising: executing a second container having a second SMT parameter equal to the first SMT parameter using the shareable configured execution cores.

6. configuring the selected execution core as exclusive; 2. The computer-implemented method of claim 1, further comprising: not executing a second container having a second SMT parameter equal to the first SMT parameter using an exclusive configured execution core.

7. A computer-executable computer program for configuring hardware multithreading in containers, the computer program causing the computer to perform the computer-implemented method of any one of claims 1 to 6.

8. The computer program of claim 7, wherein the computer program is stored in at least one of one or more storage media of a local data processing system, and the stored computer program is transferred from a remote data processing system via a network.

9. The computer program of claim 7, wherein the computer program is stored in at least one of one or more storage media of a server data processing system, and the stored computer program is downloaded to a remote data processing system over a network for use in a computer-readable storage device associated with the remote data processing system.

10. The computer program of claim 7 , wherein the computer program is provided as a service in a cloud environment.

11. 1. A computer system including one or more processors, one or more computer readable memories, and one or more computer readable storage devices, wherein program instructions are stored in at least one of the one or more computer readable storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, the program instructions being: program instructions for configuring an operating system executing on a computer system for container execution and enabling a maximum number of hardware threads per core in a set of processor cores (cores) of the computer system as part of a container initialization procedure for configuring a first container for execution on the operating system; program instructions for selecting an execution core from a set of available cores in the set of cores; program instructions for configuring a number of threads per core to be used during execution of the first container on a selected execution core, the number of threads per core being specified for the container initialization procedure by a first simultaneous multithreading (SMT) parameter; and program instructions for executing the first container using the configured execution core, the execution virtualizing the operating system.

12. 12. The computer system of claim 11, further comprising program instructions for determining the first SMT parameter from a container preference setting.

13. 12. The computer system of claim 11, wherein program instructions for configuring a number of threads per core in the selected execution core include program instructions for disabling threads in the selected execution core to obtain the number of threads per core specified by the first SMT parameter.

14. 12. The computer system of claim 11, wherein a first container core parameter specifies a number of execution cores to be selected from the set of available cores.

15. program instructions for configuring selected execution cores as shareable; and program instructions for executing a second container having a second SMT parameter equal to the first SMT parameter using the sharable configured execution core.

Images