As more and more workloads move off dedicated hardware into the cloud as virtual appliances, contention for shared hardware resource such as cache, memory and network bandwidth affects performance in the same vein as resources such as CPU and RAM. In this talk we discuss the Resource Management Daemon (RMD) architecture, components, and the design of monitor component that will track and fine tune allocations to meet service level agreements. Last but not least we share how RMD can be leveraged by cloud and container orchestration engines to effectively introduce cache allocation capabilities.

1. Lin Yang, lin.a.yang@intel.com
Sunku Ranganath, sunku.ranganath@intel.com
Joseph Gasparakis, joseph.gasparakis@intel.com
Dakshina Ilangovan, dakshina.ilangovan@intel.com

2. Last Level Cache Matters
• Cache resource contention introduces jitter
and increased latency
2
• Hardware based CPU cache control
• Allocation per process (VM, application, etc.)
• Shared and isolated usage models
• Monitoring and LLC partitioning mechanisms provide
isolation and prioritization of VMs or apps
• Software Support: Resctrl fs, PQoS toolset, Resource
Management Daemon
Intel Resource Director Technology (RDT)
Last-Level Cache Contention Can Lead to Almost 5x
Performance Variation1
1: Source: UC Berkeley (UCB) Tests, 2016, see backup for details
Technologies Support with Intel Resource Director Technology
NFV & RT workloads are time sensitive

3. Last Level Cache as a Resource – NFV use case
Figure: Traffic flow from NIC to VMs
3
Scheduling Considerations:
 Node capacity of cache
 Workload need for DDIO
 Workload sensitivity and mix
 Isolated vs. Shared allocations
Node level cache manager:
 Crucial to have local agent on the host
 Dynamic cache control
– Millisecond timescales for time
sensitive workloads
Throughput Improvement of up to 46% in presence of noisy neighbor1
1: Source: https://builders.intel.com/docs/networkbuilders/deterministic_network_functions_virtualization_with_Intel_Resource_Director_Technology.pdf

4. Allocation with Resource Management Daemon (RMD)
RMD - A Linux daemon that:
• Runs on individual hosts
• REST API, accessible to orchestrator
• Accepts & enforces policy
Open Source: https://github.com/intel/rmd
Why use RMD:
• Ability to use LLC as a resource
• Satisfies multiple usecases with
varying resource policies
[CachePool]
# total 30
guaranteed = 12
burstable= 12
besteffort = 3
[OSGroup]
cache = 3
[InfraGroup]
cache = 27
4

5. Design/Implementation Options
Features Via Libvirt Via RMD
Cache allocation &
updates
Static, One Time Configuration Dynamic, Run time updates based on
the policy
Hardware Bitmasks Operator required to understand
bitmasks for complex allocations
Hides bitmasks constraints &
calculations
Cache Policies No concept of Isolated vs. Shared
cache policies
Supports Isolated & Shared cache
policies
Hyper-Convergence May not be efficient Out of the box efficient configuration
Short timeframe
resource control
No Yes
Low level resource
control
Just at VM Level Process level control
5
RMD is complimentary to Libvirt

6. OpenStack with RMD
Scale with RMD
• Enables secure cache allocation
policies
• Manage multiple platform
resources like memory bandwidth
control using Intel RDT
6
Figure: Flavor Spec example with max_cache:min_cache model
Open for review

7. 7