QoS Policies and Architecture for Cache/Memory in CMP Platforms

QoS Policies and Architecture for Cache/Memory in CMP Platforms

Ravi Iyer, Li Zhao, Ramesh, Fei Guo, Illikkal, Steve Reinhardt

Intel Corporation, North Carolina State University, University of Michigan, Ann Arbor

ABSTRACT

CMP에 다양한 workload들이 동시에 실행되어야 하는 경우가 증가할것으로 예상되고있다. 

(급격하게 발전하고 있는 가상화 기술이 예이다,.)

각각의 workload의 Qos는 플랫폼으로 부터 얻게되고 그 Qos는 공시에 실행되는 워크로드의 동작에 따라 변할 수 있다. 

(같은 플랫폼을 공유하는 가상화 환경에서는 각VM의 Qos는 다른 VM의 영향을  주기 때문에 계산 되어야 한다.)

각 작업에 할당된 코어 수를 제어 할 수 있지만 이러한 개개의 작업 부라에 캐시 공가 및 메모리 대역폭과 같은 플랫폼 자원의 할당을 제어하는 현재의 플랫폼에서 하드웨어 또는 소프트웨어 지원은 없다. 

본 논문에서는 다음과 같은 문제를 다룬다. QoS-enabled memory architecture for CMP platforms

 QoS-enabled memory architecture는 운영체제에서 우선순위가 높은 애플리케이션에게 더많은 캐쉬와 메모리 자원를 보장하도록 한다.  본 architecture는 또한 동적으로 자원을 재할당을 가능하다. (동적으로 자원할당 우선순위를 조정한다<캐쉬,메모리자원>)

1. INTRODUCTION 

CMP는 지속적으로 발전 할것이라고 예상되는데 core의 숫자만 아니라 캐쉬나 메모리 기타 자원이 뒤따라 줘야 효율적으로 사용이 가능하다. 일반적으로 CMP는 하나의 병렬 프로그램을 잘 수행하도록 되어 있다 하지만 CMP는 여러 프로그램을 동시적으로 수행하는것 또한 가능하다. 급격하게 계발되고 있는 가상화 기술이 그 좋은 예이다. 

여러 프로그램이 CMP에서 동시에 실행 할 때 각각의 프로그램에 결정적인 Qos를 보장 할 수 없다. 그 이유는 다른 동시적으로 실행되는 workload에 많은 영향을 받기 때문이다. 최근 연구들에서 Qos를 결정적으로 하지 못하게 하는 가장큰 이유가 cache라고 설명하고 있다. 본논문에서는 이 문제를 집중적으로 본다. 

주요한 캐쉬와 메모리 자원을 바라보고 이 자원들을 효율적으로 관리 할 수 있는Qos policies를 조사하고 정의한다.   

최근 연구중에는 캐쉬를 나누는 정책은 두가지가 제시되고 있다, 공평한 분배와 불공평한 정책

본 논문 자원 우선순위를 만들어 자원을 할당하는 방법을 사용하며 어떻게 우선순위를 나눌것인가? 와 해당 우선순위에 따라 자원이 어떻게 분산 될것인지에 대하여 설명한다. 

2. A CASE FOR QOS IN CMP PLATFORMS

In this section, we motivate QoS needs by describing disparate threads and the shared resource problem. 

2.1 Disparate Threads of Execution

그림 1은 서로다른 쓰레드를 CMP에서 실행하는 방법의 경향들을 나타낸다.

a) Multi-tasking becomes more common                 : 일반적이 사용방법 

b) Virtualized workloads becoming mainstream        : 가상화 사용환경

c) Heterogeneous CMP architectures are attractive : it is also possible that either the general purpose application or the special-purpose function is more important to optimize. // 현우형 

2.2 The Shared Resource Problem

Cache and memory are two key platform resources that affect application performance.

Figure 2 illustrates the motivation for QoS in this context. The figures show the resource and performance implications of a high priority application running in standalone (dedicated) mode versus when it is running in shared mode with other low priority applications. // 높은 우선순위는 dedicate 해서 사용한다 낮은 순위의 응용프로그램을 대비하여 

3. RELATED WORK

4. QOS GOALS AND CONSIDERATIONS

In order to design appropriate QoS policies and mechanisms it is important that the goals, metrics and constraints are considered and incorporated. 

4.1 QoS Philosophy & Goals

CMP에서 최적 cache 공유방법은 3가지 타입으로 설명 할 수 있다.

capitalistic, communist, utilitarian. (자본주의, 공산주의, 실용주의)

Type 1 : capitalistic (자본주의)    : 자주 cache에 접근하는 쓰레드가 더 많은 cache 공간을 가지게 된다.

Type 2 : communist (공산주의)    : 모든 애플리케이션은 동일한 크기의 cache영역을 가지게 된다. 

Type 3 : utilitarian (실용주의)      : 시스템의 전체의 최대 throughput을 위한 분배를 한다. 

본논문은 위의 철학과 기본적이 철학이 다르다. 왜나면 APP이 동시에 실행되는 환경에서의 상대적인 우선순의를 고려해야하고 높은 우선순위의 애플리케이션이 낮은 애플리케이션 보다 많은 자원을 받도록하는것을 보장해야한다. 결과적으로 이들은 "elitist" 라고 부르는 새로운 정책을 만들었다. 

Elitist policies have several key considerations and requirements:

(a) elite application과 non-elite application을 분류해야한다. 

(b) 엘리트 응용 프로그램이 제공해야하는Qos의 특성.

(c) 비 엘리트 응용 프로그램을 고통 허용되는 범위.

4.2 QoS Metrics

The purpose of the elitist QoS policy is to improve the performance of the high priority application at the expense of others.

To specify and/or measure the efficacy of a QoS policy, we propose three types of metrics (see Figure 3):

+ Resource Usage Metrics (RUM):

높은 우선 순위의 애플리케이션의 성능을 향상시키는 기본 메카니즘은 그것이 제공되는 리소스의 양이다. 그래서 RUM (예 : 캐시 공간)는 여러 자원을 포함하는 경우 모두 자원의 QoS뿐만 아니라 전반적인 서비스 품질에 기여를 측정하는 메트릭로 사용할 수 있습니다. 플랫폼의 모든 리소스에 대한 사용 요구 사항을 지정하면 그 응용 프로그램이나 가상 머신에 맞게 가상 플랫폼 아키텍처의 생성을 가능하게한다. // 할당량 

+ Resource Performance Metrics (RPM):

더 많은 자원을 할당하는것이 항상 프로그램의 성능을 향상시킬 수 있는지는 보장 할 수 없다. //MPI

+Overall Performance Metrics (OPM):

전체 성능은 할당된 자원과 애플리케이션의 특성에 따라 결정된다. 이것을 확인하는 방법으로 가장 좋은것이 IPC이다.  //IPC

4.3 QoS Targets & Constraints

To define an appropriate QoS policy and mechanism, it is important to understand the targets and the constraints.

QoS policy의 Target은 "범위"이다. 놓은 우선순위의 애플리케이션들을 만족하는 우선순위가 낮은 애플리케이션들의 고통을 벗어나지 않는 것을 확실하게 보장해야 한다. 이것을 이해하기 위해서 Target을 정의하는것이 우선적이다. 

그림 4는 우선 순위가 높은 응용 프로그램, 우선 순위가 낮은 응용 프로그램 및 플랫폼의 전반적인 성능에 대한 경계를 설명합니다.

우선도가 높은 애플리케이션의 성능은 본질적으로 공유 모드 대 전용 모드에서의 성능에 의해 제한된다.

In this paper, we focus on best effort QoS and show how best we can provide resource and performance benefit for high priority applications while meeting the constraints. 

5. QOS POLICIES AND ARCHITECTURE

In this section, we outline proposed QoS policies based on specific goals, metrics, targets and constraints. We also present a 

QoS-aware memory architecture that forms the underlying infrastructure to implement these policies.

5.1.1 Static QoS Policies

하드웨어적으로 동적인 자원할당이 요구되지 않는경우를 위해서 정적 Qos 정책을 정의하였다. 즉 정적 정책은 지정된 대상이 자원이 지속적이 조정이 필요하지 않는 경우 사용이된다 ( ex : 특수목적 임베디드 환경)

5.1.2 Dynamic QoS Policies

Dynamic QoS requires resources to be continuously re-allocated based on the resultant performance and the targets/constraints. In this paper, we evaluate the ability to do this dynamic re-allocation in hardware. However, it should be noted that it is possible to accomplish the re-allocation in software as well if all of the monitoring feedback is provided to the execution environment (OS or VMM).

the amount of resource as well as the resultant performance provided to a high priority application or a low priority application need to be monitored at regular intervals in the platform. // 기준 RPM, OPM ( Target, LoPriConstraint, OverallConstraint )

5.2 A QoS-Aware Memory Architecture 

Our proposed QoS-aware memory architecture consists of three primary layers: priority enforcement, priority assignment and priority classification. 처음에는 두가지 우선순위 높다 낮다만 존재 한다고 생각 하고 설명을 한다. 전체 구조는 다음 그림 5와 같다. 

5.2.1 Priority Classification

우선 순위 분류 계층 정보를 식별하고 QoS를 제공 할 책임이있다.

this layer requires support in the execution environment (either OS or hypervisor) as well as the processor architecture. Operationally, support (in theform of a QoS API) is required for the user or administrator to 

supply the required QoS information to the execution environment. // OS단계의와 CPU단계의 지원이 필요하다, 사용자에게 Qos 실행환경에 대한 정보를 제공하기 위하여 

The support in the execution environment is the ability to maintain the QoS information in the thread state and the ability to save and restore it in the processor’s architectural state when the thread is scheduled to run. 

// 실행환경에 지원되는것은 스레드의 실행 상태에서 QOs정보를 유지할수 있고 저장하고 프로세서의 상태를 저장하는것이다.

The support in the processor is essentially a new control register called Platform QoS Register (PQR) in order to maintain the QoS information (in the architectural state) for the runtime. The execution environment sets the PQR with the platform priority level of the currently running application at schedule time. In addition, this register will also be used to convey the mapping of priority levels into resource thresholds (for static QoS) and the mapping of priority levels to targets/constraints (in case of dynamic QoS).  // PQR이라는 하드웨어 지원이 필요하다.

5.2.2 Priority Monitoring & Assignment

PQR정보는 초기화 과정과 그리고 자원할당의 수정이 필요할 경우 변경이 된다.  수정이 될대 마다 QRT에 전달되게 된다.

타겟은 1.2로 지정되는 경우, 예를 들어, 다음 목표 메트릭으로서 OPM을 사용할 경우 20 % 이상의 성능 (IPC)을 달성하는 것이다.

우선 순위 레벨의 매핑은 자원하거나 성과 목표를 설정하고 나면,

다음 단계는 모든 메모리 액세스는 우선 순위 레벨로 태그되어 있는지 확인하는 것이다.

5.2.3 Priority Enforcement 

The inputs to the enforcement layer are the tagged memory accesses and the QoS resource table.

As shown in Figure 7, each line in the cache is tagged with the priority level in order to keep track of the current cache space utilization per priority level. The QoS resource table uses this information to store the cache utilization per priority level. 이는 단순히 새로운 라인이 캐시에 할당되면 자원 사용량을 증가 및 보충 또는 퇴거 발생시 리소스 사용을 감소시키는 의해 수행된다. The QoS resource table also maintains the number of memory accesses (cache misses and writebacks). 이렇게함으로써, 또한 메모리 대역폭 소모를 추적 할 수있다.

priority enforcement에는 중요한 두가지 이상의 기능이 있다. 

(a) Static QoS: to make sure the resource utilization stays within the static QoS threshold specified in the QoS Resource Table

(b) Dynamic QoS: to dynamically adjust the threshold to satisfy the performance target/constraint specified.

6. QOS EVALUATION & PROTOTYPING

In this section, we present two approaches (trace-driven simulation & software prototyping) to evaluate QoS.

6.1 Simulation-Based Evaluation

In this subsection, we describe the trace-driven simulations for evaluating QoS policies and architecture. 

6.1.1 Simulation Framework

We developed a trace-driven platform simulator called ManySim to evaluate CMP architectures and QoS policies.

ManySim simulates the platform resources with high accuracy, but abstracts the core to optimize for speed.

There are two cores, with each one having four threads and its own private L1 and L2. Both cores share the last level cache (L3) where the QoS policies are enforced.When we run multi-threaded applications with two priority levels, each core is running a different application (the first four threads run the high priority application whereas the second four threads run the low priority application).When we run three applications with three different priority levels, the high, mid and low priority applications are running on the first three threads, the next three and the last two threads respectively. // 실헙 환경

Table 1 summarizes the simulation configurations.

ManySim was modified to allow cores and traces to be tagged with priorities. The priorities were then provided to the cache/memory subsystem. The QoS hardware components (QRT, QEM, QoSaware replacement, etc) were implemented in ManySim. // 엘리트 Qos 정책을 하기 위한 하드웨어 지원도 시뮬레이션에 추가 하였다. 

We also evaluate memory QoS for the base architecture with and without cache QoS. //캐쉬없이 메모리만으로도 테스트한다. 

6.1.2 Workloads & Traces

We chose a few commercial multi-threaded server workloads (OLTP, SPECjbb) and a networking workload (NTttcp).

6.1.3 Evaluating Static QoS Impact 

our evaluation of the static QoS policy is done by varying this cache space limit for low priority applications from 0% to 40% of the cache size. We compare this to the shared mode execution without QoS which is denoted by a cache space limit of 100%. // 성능 평가 방법 low priority application 40%로 한정짓는 방법과 100%설정했을때를 비교한다,.

Figure 10 shows the impact of the QoS policy when executing TPCC with SPECjbb and TPCC and NTttcp.

One of the important findings from this study is that since the low priority application gets affected, it is important to enforce constraints on how degraded its performance can get.

It should be noted that there are two “opposite” memory effects occurring as more cache space is provided to the high priority application: // 높은 우선순위에 더 많은 캐쉬를 주면 다음과 같은 현상이 발생하게 된다. 

(a) fewer high priority misses go to the memory subsystem and as a result, the dependency on memory bandwidth is lower // 높은 우선순위는 메모리 밴드 위스가 줄어 들게 된다 캐쉬에 공간이 많기 때문에 메모리 서브 시트템은 낮은 메모리 대여폭을 제공하게 된다.

(b) more low priority misses go to the memory subsystem and as a result, it occupies more of the memory bandwidth.  // 반면 낮은 우선순위는 메모리에 빈번하게 접근하여 높은 메모리 대여폭을 가지게 된다. 

6.1.4 Evaluating Dynamic QoS Impact 

For dynamic QoS, we only present the impact of the policy on cache for lack of space.

6.2 QoS Prototyping

To evaluate our QoS-aware architecture more realistically, we developed a software prototype and ran a limited set of experiments on a full system simulator. In this section, we describe this effort and our initial findings. 

// 시뮬레이션은 하드웨어적인 지원이 가능하다고 실험을 한것이고 이 경우는 실제 환경에서 소프트웨어적인 방법으로 구현하여 제한 적인 실험한 결과이다. 

6.2.1 QoS-Aware Operating System

Our software prototype is a QoS-aware Linux operating system. This was accomplished by modifying the 2.6.16 Linux kernel to provide the following QoS support:

(a) QoS bits in process state: 

(b) QoS register emulation:

(a) QoS APIs for user/administrator:

(b) QoS utility program:

6.2.2 Full-System Simulation 

6.2.3 QoS Evaluation