KR20180034960A - 플랫폼 관리 장치 및 방법 - Google Patents

Abstract

플랫폼 관리 장치 및 방법이 개시된다. 본 발명의 일실시예에 따른 플랫폼 관리 장치는 어플리케이션들의 설정 정책을 전달 받아 디바이스들을 검사하여 계산 유닛들의 수를 결정하는 정책 관리부 및 상기 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하고, 상기 어플리케이션들을 상기 계산 유닛들에 할당하는 디바이스 관리부를 포함한다.

Description

플랫폼 관리 장치 및 방법 {APPRATUS FOR MANAGING PLATFORM AND METHOD FOR USING THE SAME}

본 발명은 컴퓨터 기술에 관한 것으로, 보다 상세하게는 Open CL 기반 시스템의 관리 기술에 관한 것이다.

최근 CPU의 발전 방향을 살펴보면 에너지 효율을 위해서 성능이 다른 여러 종류의 코어를 하나의 칩에 넣는 이종시스템(Heterogeneous system)이 발전하고 있다. 또한, GPU에서는 GPGPU의 발전과 함께 많은 수의 코어가 존재하는 매니코어(manycore) 시스템이 대중화 되고 있다. 이에 따라 이종 시스템에서 데이터를 병렬적으로 처리하는 소프트웨어기술이 소개되고 있는데, 대표적인 것이 Khronos 그룹에서 제안한 OpenCL(Open Computing Language)이다. OpenCL은 다수의 이종 프로세서 및 매니코어 시스템에서 데이터를 병렬적으로 처리할 수 있게 도와주는 프레임워크이다.

하나의 머신에는 여러 OpenCL 계산 디바이스가 존재하며 하나의 디바이스는 각각 여러 개여 계산 유닛(Computing Unit; CU)을 제공한다. 예를 들어, X사(社)의 CPU와 Y사(社)의 그래픽카드가 하나의 머신에 존재하고 서로 협업하여 계산을 수행하는 환경이라면, 2개의 디바이스가 각각 여러 개의 계산 유닛을 제공하여 연산을 수행하는 형태가 된다. OpenCL 프레임워크에서는 하나 이상의 디바이스를 묶어서 플랫폼(Platform)이라고 불리며, 주로 하나의 하드웨어 벤더가 하나의 플랫폼을 제공한다. OpenCL 프레임워크에서는 여러 플랫폼을 관리하기 위해 ICD(Installable Client Device) 로더가 존재한다. ICD 로더는 시스템에서 하나만 존재 할 수 있으며, 어플리케이션들은 ICD 로더를 통해서 OpenCL 명령을 수행할 수 있다.

OpenCL 시스템은 여러 어플리케이션이 동시에 같은 컴퓨팅 디바이스를 사용할 수 있기 때문에, 하나의 어플리케이션은 같이 수행하는 어플리케이션에 따라 품질의 저하가 나타날 수 있다. 따라서 특정 어플리케이션이 수행 중일 때 다른 어플리케이션의 동작에 영향을 받지 않고 성능을 보장할 수 있는 시스템이 필요하다.

한편, 한국등록특허 제10-1284195호“개방형 범용 병렬 컴퓨팅 프레임워크 동적 작업 분배 장치”는 커널의 수행 시점에 기반하여 코어의 작업을 분배하는 장치에 관하여 개시하고 있다.

본 발명은 전술한 어플리케이션간의 간섭으로 인한 성능 저하 문제를 해결하는 것을 목적으로 한다.

또한, 본 발명은 여러 개의 OpenCL 어플리케이션이 하나의 OpenCL 디바이스를 사용할 경우 발생하는 성능 간섭을 최소화하는 것을 목적으로 한다.

또한, 본 발명은 정책에 따라 특정 어플리케이션이 OpenCL 디바이스의 일부를 전용으로 사용할 수 있는 시스템 및 방법을 제공하는 것을 목적으로 한다.

또한, 본 발명은 기존의 어플리케이션과 플랫폼 드라이버의 수정 없이 기존 시스템에도 그대로 적용하는 것을 목적으로 한다.

또한, 본 발명은 메모리 계층도에 따라 파티셔닝하는 알고리즘을 이용하여 시스템의 성능을 극대화하는 것을 목적으로 한다.

상기한 목적을 달성하기 위한 본 발명의 일실시예에 따른 플랫폼 관리 장치는 어플리케이션들의 설정 정책을 전달 받아 디바이스들을 검사하여 계산 유닛들의 수를 결정하는 정책 관리부 및 상기 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하고, 상기 어플리케이션들을 상기 계산 유닛들에 할당하는 디바이스 관리부를 포함한다.

또한, 상기한 목적을 달성하기 위한 본 발명의 일실시예에 따른 플랫폼 관리 방법은 플랫폼 관리 장치를 이용하는 방법에 있어서, 어플리케이션들의 설정 정책을 전달 받아 디바이스 및 계산 유닛들의 수를 검사하는 단계; 상기 디바이스 및 계산 유닛들의 수를 결정하는 단계; 상기 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하여 상기 어플리케이션들을 상기 계산 유닛들에 할당하는 단계를 포함한다.

본 발명은 전술한 어플리케이션간의 간섭으로 인한 성능 저하 문제를 해결할 수 있다.

또한, 본 발명은 여러 개의 OpenCL 어플리케이션이 하나의 OpenCL 디바이스를 사용할 경우 발생하는 성능 간섭을 최소화할 수 있다.

또한, 본 발명은 정책에 따라 특정 어플리케이션이 OpenCL 디바이스의 일부를 전용으로 사용할 수 있는 시스템 및 방법을 제공할 수 있다.

또한, 본 발명은 기존의 어플리케이션과 플랫폼 드라이버의 수정 없이 기존 시스템에도 그대로 적용할 수 있다.

또한, 본 발명은 메모리 계층도에 따라 파티셔닝하는 알고리즘을 이용하여 시스템의 성능을 극대화할 수 있다.

도 1은 본 발명의 일실시예에 따른 플랫폼 관리 시스템을 나타낸 블록도이다.
도 2는 본 발명의 일실시예에 따른 플랫폼 관리 시스템에서 플랫폼 관리 장치를 세부적으로 나타낸 블록도이다.
도 3은 본 발명의 일실시예에 따른 어플리케이션의 디바이스 할당을 나타낸 도면이다.
도 4는 본 발명의 일실시예에 따른 계산 유닛을 나타낸 도면이다.
도 5는 본 발명의 일실시예에 따른 플랫폼 관리 방법을 나타낸 동작흐름도이다.

본 발명을 첨부된 도면을 참조하여 상세히 설명하면 다음과 같다. 여기서, 반복되는 설명, 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능, 및 구성에 대한 상세한 설명은 생략한다. 본 발명의 실시형태는 당 업계에서 평균적인 지식을 가진 자에게 본 발명을 보다 완전하게 설명하기 위해서 제공되는 것이다. 따라서, 도면에서의 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 1은 본 발명의 일실시예에 따른 플랫폼 관리 시스템을 나타낸 블록도이다.

도 1을 참조하면, OpenCL 어플리케이션A,B가 ICD 로더에 상응하는 플랫폼 관리 장치(100)에 의해 플랫폼 1, 2의 CPU와 GPU에 할당되는 것을 알 수 있다.

OpenCL 플랫폼 관리 시스템은 여러 어플리케이션이 동시에 같은 컴퓨팅 디바이스를 사용할 수 있기 때문에, 하나의 어플리케이션은 같이 수행하는 어플리케이션에 따라 품질의 저하가 나타날 수 있다.

예를 들어, 어플리케이션A가 X사(社) CPU를 이용하여 작업을 수행 중인데, 어플리케이션B가 X사(社)의 GPU 혹은 Y사(社)의 GPU를 이용하여 작업을 수행한다면 어플리케이션A에 주는 영향이 미미하지만, X사(社)의 CPU를 이용한다면 어플리케이션A에서는 눈에 띄는 성능의 저하가 나타나게 된다. 어플리케이션은 자신이 모든 자원을 차지하여 최고의 성능을 내려고 하기 때문에, 이런 어플리케이션들이 여러 개가 수행 중이라면 성능의 저하는 피할 수가 없다.

도 2는 본 발명의 일실시예에 따른 플랫폼 관리 시스템에서 플랫폼 관리 장치를 세부적으로 나타낸 블록도이다.

도 2를 참조하면, 본 발명의 일실시예에 따른 플랫폼 관리 장치(100)는 정책 관리부(110)와 디바이스 관리부(120)를 포함한다.

플랫폼 관리 장치(100)는 성능 격리 기능이 추가된 ICD 로더에 상응할 수 있다.

정책 설정 어플리케이션은 어플리케이션들의 정책을 설정할 수 있다.

정책 관리부(110)는 정책 설정 어플리케이션에서 설정한 설정 정책을 받아 올 수 있다.

이 때, 어플리케이션이 플랫폼 관리 장치(100)에 작업 요청을 보내면, 정책 관리부(110)는 정책에 설정이 된 어플리케이션인지 확인할 수 있다.

이 때, 정책 관리부(110)는 어플리케이션들의 설정 정책을 전달 받아 디바이스들을 검사하여 계산 유닛들의 수를 결정할 수 있다.

만약, 정책에서 디바이스 및 계산 유닛을 할당하지 않은 어플리케이션이라면, 작업 요청을 수행하지 않는다. 디바이스 및 계산 유닛이 할당 되었다면, 정책 관리부(100)는 정책에 동일한 디바이스에 할당 된 다른 어플리케이션이 있는지 확인할 수 있다.

이 때, 정책 관리부(110)는 OpenCL 성능 격리 시스템을 사용하기 위하여 먼저 어플리케이션 별로 사용 가능한 디바이스 및 계산 유닛의 수를 결정할 수 있다. 정책의 설정을 위해 정책 설정 어플리케이션을 수행하면, 플랫폼 관리 장치(100)에서는 각각의 OpenCL 디바이스들을 검사하여 디바이스 별로 다음과 같은 형태로 사용자에게 알려줄 수 있다.

여기서 디바이스ID는 OpenCL 디바이스를 구분해 주는 고유한 ID에 상응할 수 있고, 디바이스 형태는 CPU, GPU, DSP 등 디바이스의 종류에 상응할 수 있다. 계산 유닛의 수는 총 사용 가능한 계산 유닛의 수에 상응할 수 있다.

이를 바탕으로 하여, 사용자는 각각의 어플리케이션에 대해서 사용할 디바이스와 계산 유닛을 다음과 같은 형태로 지정하여 정책 관리 모듈에게 알려줄 수 있다.

이 때, 어플리케이션ID는 특정 어플리케이션을 지칭하는 ID, 실행파일명, 실행파일 경로, 혹은 실행파일 해쉬 값 등 어플리케이션을 구분할 수 있는 다양한 형태가 사용될 수 있다. 디바이스ID는 정책 설정 어플리케이션에게 반환했던 디바이스ID에 상응할 수 있고, 계산 유닛수는 지정한 어플리케이션에게 할당 된 계산 유닛의 수를 지정할 수 있다.

이후에 어플리케이션이 실제 OpenCL 사용을 위해서 플랫폼 관리 장치(100)를 이용하여 OpenCL 디바이스에 접근을 하려고 하면, 플랫폼 관리 장치(100)는 정책 어플리케이션에서 설정된 디바이스만을 OpenCL 어플리케이션에게 노출할 수 있고, OpenCL어플리케이션은 정책에서 설정된 OpenCL 디바이스와 계산 유닛 이외에는 사용할 수 없다.

디바이스 관리부(120)는 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하고, 상기 어플리케이션들을 상기 계산 유닛들에 할당할 수 있다.

ICD 로더에 상응하는 플랫폼 관리 장치(100)는 기존의 OpenCL 규격에 맞춰 OpenCL 어플리케이션에게 노출되고, 플랫폼도 기존의 OpenCL 규격에 맞춰져 있으므로, OpenCL 어플리케이션 및 플랫폼 드라이버의 수정 없이 기존 ICD 로더에 기능만 추가하여 사용할 수 있다.

다른 어플리케이션이 없다면, 디바이스 관리부(120)는 그 어플리케이션에 디바이스의 계산 유닛 전체에 접근 권한을 생성할 수 있다. 만약 두 개 이상의 어플리케이션이 하나의 디바이스에 할당이 되어 있다면, 디바이스 관리부(120)는 디바이스의 계산 유닛을 파티셔닝 하여 (partitioning or fission) 여러 개의 서브 디바이스로 만든 다음 나누어진 서브 디바이스만을 어플리케이션에게 할당 할 수 있다. 서브 디바이스를 만들기 위해서는 플랫폼 드라이버에서 이를 지원해야 하는데, OpenCL 1.2 프로파일을 만족하는 플랫폼이라면 clCreateSubDevices() 함수 등 디바이스를 나누는 방법을 제공하기 때문에 이를 이용해서 서브 디바이스로 나눠줄 수 있다.

도 3은 본 발명의 일실시예에 따른 어플리케이션의 디바이스 할당을 나타낸 도면이다.

도 3을 참조하면, 어플리케이션A는 X사(社)의 디바이스에 단독으로 할당이 되어 있기 때문에, 정책에서 제시한 계산 유닛의 수와 상관없이 디바이스 전체의 계산 유닛을 어플리케이션 A에게 할당 할 수 있다. 어플리케이션B와 어플리케이션C의 경우 하나의 디바이스에 할당되어 있기 때문에, 이런 경우라면, Y사(社) CPU 디바이스를 서브 디바이스로 나누어서 어플리케이션B과 어플리케이션C에 할당 할 수 있다. 어플리케이션B와 어플리케이션C에서는 정책에서 할당된 수만큼의 계산 유닛이 보이게 되므로 그 이상의 계산 유닛을 사용할 수 없다.

디바이스 관리부(120)는 하나의 디바이스를 서브 디바이스로 나눌 때, 계산 유닛 간 캐쉬를 공유하게 하여 최대한 성능을 높일 수 있다.

이 때, 계산 유닛들 사이에 공유 정도에 따라 메모리 계층이 존재할 수 있다.

도 4는 본 발명의 일실시예에 따른 계산 유닛을 나타낸 도면이다.

도 4를 참조하면, CPU에서의 메모리 계층도의 예시이다. GPU도 이와 비슷한 형태에 상응할 수 있다. 계산 유닛, 스트리밍 멀티프로세서, 프로세서 클러스터 등 여러 형태의 메모리 계층이 존재하며, 이들은 디바이스마다 상이하므로, 본 발명에서는 이를 추상화 한 상태에서 설명한다. 계산 유닛 간 공유하는 메모리가 다르므로, 최대한 같은 메모리를 공유하는 계산 유닛을 하나의 서브 디바이스에 할당할 수 있다. 따라서 다음 알고리즘을 이용하여 최적의 서브 디바이스를 나눌 수 있다.

하나의 디바이스에 할당된 어플리케이션 n개에 대해 정책에서 할당된 계산 유닛의 수가 (c₁, c₂,…,c_n) 이고, 메모리 계층도에서 존재하는 공유 메모리의 높이를 k라고하자. (레벨1은 가장 많은 계산 유닛이 공유하는 메모리이고, 레벨k는 가장 적은 계산 유닛이 공유하는 메모리이다.) 레벨 i의 메모리에서 파티셔닝을 할 경우 생성할 수 있는 서브 디바이스 수를 d_i 라고 하고, 서브 디바이스당 계산 유닛의 수를 s_i라고 할 때, 다음을 수행한다.

FOR 1≤i≤k

IF d_i≥n AND s_i≥max(c₁,c₂,…,c_n)

각각에 어플리케이션에 d_i 개의 서브 디바이스 중 하나씩을 할당 종료

ENDIF

ENDFOR

// 위 루프 내에서 종료되지 않았다면, 정책을 만족시키면서 메모리를 공유하는 계산 유닛을 찾을 수 없다.

// 이 경우 메모리 공유를 계산하지 않고 할당.

// 어플리케이션 별로 필요 계산 유닛을 순차적으로 할당.

디바이스 관리부(120)는 위 알고리즘을 이용하여, 정책을 만족시키면서 계산 유닛끼리 최대한 큰 메모리를 공유하는 파티셔닝 방법을 찾을 수 있다.

즉, 디바이스 관리부(120)는 도 4에 도시된 바와 같이, NUMA메모리, L4, L3, L2, L1의 순으로 파티셔닝을 하면서 정책을 만족시키는 파티셔닝 방법을 찾을 수 있다. 따라서, 계산 유닛끼리 더 많은 메모리를 공유할 수 있고, 이에 따라 계산 유닛끼리 데이터를 공유하는 경우, 성능을 향상시킬 수 있다.

도 5는 본 발명의 일실시예에 따른 플랫폼 관리 방법을 나타낸 동작흐름도이다.

도 5를 참조하면, 본 발명의 일실시예에 따른 플랫폼 관리 방법은 먼저 디바이스 및 계산 유닛 수를 검사할 수 있다(S210).

즉, 단계(S210)는 정책 설정 어플리케이션에서 설정한 설정 정책을 받아 올 수 있다.

이 때, 단계(S210)는 어플리케이션들의 설정 정책을 전달 받아 디바이스들을 검사하여 계산 유닛들의 수를 결정할 수 있다.

이 때, 단계(S210)는 어플리케이션이 플랫폼 관리 장치(100)에 작업 요청을 보내면, 정책 관리부(110)는 정책에 설정이 된 어플리케이션이지 확인할 수 있다. 만약, 정책에서 디바이스 및 계산 유닛을 할당하지 않은 어플리케이션이라면, 작업 요청을 수행하지 않는다.

이 때, 단계(S210)는 디바이스 및 계산 유닛이 할당 되었다면, 정책에 동일한 디바이스에 할당 된 다른 어플리케이션이 있는지 확인할 수 있다.

또한, 본 발명의 일실시예에 따른 정책 플랫폼 관리 방법은 디바이스 및 계산 유닛 수를 결정할 수 있다(S220).

즉, 단계(S220)는 OpenCL 성능 격리 시스템을 사용하기 위하여 먼저 어플리케이션 별로 사용 가능한 디바이스 및 계산 유닛의 수를 결정할 수 있다. 정책의 설정을 위해 정책 설정 어플리케이션을 수행하면, 플랫폼 관리 장치(100)에서는 각각의 OpenCL 디바이스들을 검사하여 디바이스 별로 다음과 같은 형태로 사용자에게 알려줄 수 있다.

여기서 디바이스ID는 OpenCL 디바이스를 구분해 주는 고유한 ID에 상응할 수 있고, 디바이스 형태는 CPU, GPU, DSP 등 디바이스의 종류에 상응할 수 있다. 계산 유닛의 수는 총 사용 가능한 계산 유닛의 수에 상응할 수 있다.

이를 바탕으로 하여, 사용자는 각각의 어플리케이션에 대해서 사용할 디바이스와 계산 유닛을 다음과 같은 형태로 지정하여 정책 관리 모듈에게 알려줄 수 있다.

이 때, 어플리케이션ID는 특정 어플리케이션을 지칭하는 ID, 실행파일명, 실행파일 경로, 혹은 실행파일 해쉬 값 등 어플리케이션을 구분할 수 있는 다양한 형태가 사용될 수 있다. 디바이스ID는 정책 설정 어플리케이션에게 반환했던 디바이스ID에 상응할 수 있고, 계산 유닛수는 지정한 어플리케이션에게 할당 된 계산 유닛의 수를 지정할 수 있다.

이후에 어플리케이션이 실제 OpenCL 사용을 위해서 플랫폼 관리 장치(100)를 이용하여 OpenCL 디바이스에 접근을 하려고 하면, 플랫폼 관리 장치(100)는 정책 어플리케이션에서 설정된 디바이스만을 OpenCL 어플리케이션에게 노출할 수 있고, OpenCL어플리케이션은 정책에서 설정된 OpenCL 디바이스와 계산 유닛 이외에는 사용할 수 없다.

또한, 본 발명의 일실시예에 따른 플랫폼 관리 방법은 계산 유닛을 파티셔닝 하고 어플리케이션을 계산 유닛에 할당 할 수 있다(S230).

즉, 단계(S230)는 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하고, 상기 어플리케이션들을 상기 계산 유닛들에 할당할 수 있다.

ICD 로더에 상응하는 플랫폼 관리 장치(100)는 기존의 OpenCL 규격에 맞춰 OpenCL 어플리케이션에게 노출되고, 플랫폼도 기존의 OpenCL 규격에 맞춰져 있으므로, OpenCL 어플리케이션 및 플랫폼 드라이버의 수정 없이 기존 ICD 로더에 기능만 추가하여 사용할 수 있다.

다른 어플리케이션이 없다면, 단계(S230)는 어플리케이션에 디바이스의 계산 유닛 전체에 접근 권한을 생성할 수 있다. 만약 두 개 이상의 어플리케이션이 하나의 디바이스에 할당이 되어 있다면, 단계(S230)는 디바이스의 계산 유닛을 파티셔닝하여(partitioning or fission) 여러 개의 서브 디바이스로 만든 다음 나누어진 서브 디바이스만을 어플리케이션에게 할당 할 수 있다. 서브 디바이스를 만들기 위해서는 플랫폼 드라이버에서 이를 지원해야 하는데, OpenCL 1.2 프로파일을 만족하는 플랫폼이라면 clCreateSubDevices() 함수 등 디바이스를 나누는 방법을 제공하기 때문에 이를 이용해서 서브 디바이스로 나눠줄 수 있다.

도 3을 참조하면, 어플리케이션A는 X사(社)의 디바이스에 단독으로 할당이 되어 있기 때문에, 정책에서 제시한 계산 유닛의 수와 상관없이 디바이스 전체의 계산 유닛을 어플리케이션 A에게 할당 할 수 있다. 어플리케이션B와 어플리케이션C의 경우 하나의 디바이스에 할당되어 있기 때문에, 이런 경우라면, Y사(社) CPU 디바이스를 서브 디바이스로 나누어서 어플리케이션B과 어플리케이션C에 할당 할 수 있다. 어플리케이션B와 어플리케이션C에서는 정책에서 할당된 수만큼의 계산 유닛이 보이게 되므로 그 이상의 계산 유닛을 사용할 수 없다.

또한, 단계(S230)는 하나의 디바이스를 서브 디바이스로 나눌 때, 계산 유닛 간 캐쉬를 공유하게 하여 최대한 성능을 높일 수 있다.

이 때, 계산 유닛들 사이에 공유 정도에 따라 메모리 계층을 포함할 수 있다.

도 4를 참조하면, CPU에서의 메모리 계층도의 예시이다. GPU도 이와 비슷한 형태에 상응할 수 있다. 계산 유닛, 스트리밍 멀티프로세서, 프로세서 클러스터 등 여러 형태의 메모리 계층이 존재하며, 이들은 디바이스마다 상이하므로, 본 발명에서는 이를 추상화 한 상태에서 설명한다. 계산 유닛 간 공유하는 메모리가 다르므로, 최대한 같은 메모리를 공유하는 계산 유닛을 하나의 서브 디바이스에 할당할 수 있다. 따라서 다음 알고리즘을 이용하여 최적의 서브 디바이스를 나눌 수 있다.

하나의 디바이스에 할당된 어플리케이션 n개에 대해 정책에서 할당된 계산 유닛의 수가 (c₁, c₂,…,c_n) 이고, 메모리 계층도에서 존재하는 공유 메모리의 높이를 k라고하자. (레벨1은 가장 많은 계산 유닛이 공유하는 메모리이고, 레벨k는 가장 적은 계산 유닛이 공유하는 메모리이다.) 레벨 i의 메모리에서 파티셔닝을 할 경우 생성할 수 있는 서브 디바이스 수를 d_i 라고 하고, 서브 디바이스당 계산 유닛의 수를 s_i라고 할 때, 다음을 수행한다.

FOR 1≤i≤k

IF d_i≥n AND s_i≥max(c₁,c₂,…,c_n)

각각에 어플리케이션에 d_i 개의 서브 디바이스 중 하나씩을 할당 종료

ENDIF

ENDFOR

// 위 루프 내에서 종료되지 않았다면, 정책을 만족시키면서 메모리를 공유하는 계산 유닛을 찾을 수 없다.

// 이 경우 메모리 공유를 계산하지 않고 할당.

// 어플리케이션 별로 필요 계산 유닛을 순차적으로 할당.

단계(S230)는 위 알고리즘을 이용하여, 정책을 만족시키면서 계산 유닛끼리 최대한 큰 메모리를 공유하는 파티셔닝 방법을 찾을 수 있다.

즉, 단계(230)는 도 4에 도시된 바와 같이, NUMA메모리, L4, L3, L2, L1의 순으로 파티셔닝을 하면서 정책을 만족시키는 파티셔닝 방법을 찾을 수 있다. 따라서, 계산 유닛끼리 더 많은 메모리를 공유할 수 있고, 이에 따라 계산 유닛끼리 데이터를 공유하는 경우 성능을 향상시킬 수 있다.

이상에서와 같이 본 발명에 따른 플랫폼 관리 장치 및 방법은 상기한 바와 같이 설명된 실시예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시예들은 다양한 변형이 이루어질 수 있도록 각 실시예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.

110: 정책 관리부
120: 디바이스 관리부

Claims (1)

1. 어플리케이션들의 설정 정책을 전달 받아 디바이스들을 검사하여 계산 유닛들의 수를 결정하는 정책 관리부; 및
   상기 설정 정책과 상기 계산 유닛들의 수에 기반하여 상기 계산 유닛들을 파티셔닝(partitioning)하고, 상기 어플리케이션들을 상기 계산 유닛들에 할당하는 디바이스 관리부;
   를 포함하는 것을 특징으로 하는 플랫폼 관리 장치.

Images