Search

EP-4273704-B1 - TECHNIQUES TO SUPPORT A HOLISTIC VIEW OF CACHE CLASS OF SERVICE FOR A PROCESSOR CACHE

EP4273704B1EP 4273704 B1EP4273704 B1EP 4273704B1EP-4273704-B1

Inventors

  • BHANDARU, MALINI K.
  • YANG, Lin A.
  • GASPARAKIS, Iosif
  • RANGANATH, SUNKU
  • QIAO, Liyong
  • ZANG, Rui
  • ILANGOVAN, Dakshina
  • FENG, Shaohe
  • VERPLANKE, Edwin
  • AUTEE, PRIYA

Dates

Publication Date
20260506
Application Date
20180629

Claims (6)

  1. An apparatus comprising: a computing platform (110) comprising circuitry to execute logic to: receive information to allocate processor cache resources to a plurality of class of service, CLOS, the allocated processor cache resources to include an n-way set-associative last level cache, LLC, (144) for a processor (140) hosted by the computing platform (110), where "n" is any whole, positive number greater than or equal to 1; and cause one or more cache ways of the n-way set associative LLC (144) to be allocated to separate CLOS of the plurality of CLOS characterised in that the allocation is based on the information including identification information that matches identification information for at least the processor (140) hosted by the computer platform (110); wherein the plurality of CLOS comprises a plurality of predefined CLOS that includes a host operating system, OS, (111) CLOS; and wherein the logic is further to implement a policy to reserve at least one cache way of the n-way set associative LLC (144) for allocation only to the host OS (111) CLOS.
  2. The apparatus of claim 1, further comprising the logic to: monitor usage of the plurality of CLOS while the computing platform supports one or more workloads to determine processor cache resource pressure; and report the determined processor cache resource pressure through the REST API or the RPC API to an orchestrator of the network coupled to the computing platform.
  3. The apparatus of claim 2, comprising the logic to report determined processor cache resource pressure on a periodic basis or report determined processor cache resource pressure responsive to receiving a list-resource call from the orchestrator through the REST API or the RPC API.
  4. The apparatus of claim 1, the plurality of CLOS comprising a plurality of predefined CLOS further including an infrastructure processes CLOS, a burstable CLOS, a best effort CLOS or a guaranteed pool CLOS.
  5. The apparatus of claim 4, further comprising the logic to: implement a policy to have the best effort CLOS be a default CLOS if a CLOS from among the plurality of CLOS is not requested by an application being executed by the processor, the best effort CLOS to have allocated cache ways that are shared with the infrastructure processes CLOS and burstable CLOS.
  6. The apparatus of claim 4, further comprising the logic to: implement a policy to reserve a portion of cache ways of the guaranteed pool CLOS for an application being executed by the processor, the portion of the cache ways reserved based on whether one or more cache ways of the guaranteed pool CLOS are not reserved by a different application being executed by the processor.

Description

TECHNICAL FIELD Examples described herein are generally related to processor cache allocation via use of cache class of service (CLOS). BACKGROUND A processor of a computing platform coupled to a network (e.g., in a datacenter) may be associated with various types of resources that may be allocated to an application hosted by the computing platform. The various types of resources may include, but are not limited to, central processing unit (CPU) cores, system memory such as random access memory, network bandwidth or processor cache (e.g., last-level-cache (LLC)) . Performance requirements for the application that may be based on service level agreements (SLAs) or general quality of service (QoS) requirements may make it necessary to reserve or allocate one of more of these various types of resources to ensure SLAs and/or QoS requirements are met. WO 2016/085642 A1 discloses an apparatus according to the preamble of claim 1. SUMMARY The invention is set out in the appended set of claims. The dependent claims set out particular embodiments. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates an example first system.FIG. 2 illustrates an example Class of Service (CLOS) map.FIG. 3 illustrates an example code.FIG. 4 illustrates an example second system.FIG. 5 illustrates an example process.FIG. 6 illustrates an example block diagram for an apparatus.FIG. 7 illustrates an example of a logic flow.FIG. 8 illustrates an example of a storage medium.FIG. 9 illustrates an example computing platform. DETAILED DESCRIPTION Relatively new technologies such as Intel® Resource Director Technology (RDT) allow for monitoring usage and allocation of processor cache that is mainly focused on defining cache classes of service (CLOS) and how to use bit masks such as capacity bitmasks (CBMs) to partition the processor cache to support the CLOS. In some implementations for these new technologies such as Intel® RDT, users may be able to use machine specific registers directly to partition the processor cache to support the CLOS. In other implementations, users may use kernel support such as Intel® developed Linux kernel support or access software libraries to assist in partitioning the processor cache to support the CLOS. However, these new technologies such as Intel® RDT currently tend to focus on the mechanics of monitoring and allocating the processor cache for a given application hosted by a computing platform rather than have a more holistic view of performance gains for the entire computing platform when allocating the processor cache to support the CLOS. This holistic view may be dependent on which workloads, including the computing platform's operating system (OS) are assigned to which processor cache partitions and whether assigned processor cache partitions are shared between two or more CLOS. FIG. 1 illustrates an example system 100. In some examples, as shown in FIG. 1, system 100 includes a computing platform 110 coupled through a network 150 with an orchestrator 160. For these examples, system 100 may be part of a datacenter and network 150 may represent elements of an internal network that communicatively couples a plurality of computing platforms, servers or nodes included in the datacenter such as communicatively coupling computing platform 110 with various other servers or nodes. According to some examples, computing platform 110 may be a node composed of disaggregated resources (i.e., a node comprised of compute resources from a compute sled, storage resources from a storage sled, accelerator resources from an accelerator sled) in a datacenter to support VMs separately executing one or more applications such as providing network services and/or a network function to clients or customers. For example, VMs 130-1 to 130-n (where "n" represents any whole, positive integer greater than 1) and may be supported by composed computing resources associated with computing platform 110. VMs 130-1 to 130-n at computing platform 110 may be managed or controlled by a hypervisor/VM manager (VMM) such as hypervisor/VMM 112. In other examples, computing platform 110 may be configured as a more conventional server having the various above-mentioned computing resources contained within the same physical enclosure, chassis or container. In some examples, as shown in FIG. 1, at least some of the composed computing resources for computing platform 110 may include a processor 140 having processing elements such as CPU/cores 142-1 to 142-n having a shared last-level cache (LLC) 144. CPU/cores 142-1 to 142-n may have shared access to LLC 144 to support respective VMs 130-1 to 130-n, applications (App(s)) 132-1 to 132-n, guest operating systems (OSs) 134-1 to 134-n, host OS 111 or infrastructure (Infra) processes 117. As described in more detail below, the shared access to LLC 144 by CPU/cores 142-1 to 142-n may be associated with a CLOS map that is managed by logic and/or features of a resource manager daemon (RMD) 113. The CLOS map may in