Current Issue

멀티코어 시스템에서는 시스템의 처리량을 높이기 위해 그림 1의 (a)와 같이 다수의 코어에서 여러 태스크를 동시에 실행한다. 하지만 여러 태스크에서 동시에 메모리 읽기, 쓰기 작업을 하면 버스, 메모리 등의 하드웨어 자원 사용에 대한 간섭이 발생한다. 이러한 간섭은 각 태스크의 실행 시간 증가로 인한 예측성 저하와 같은 문제를 발생시킬 수 있으므로 RTOS에서는 간섭을 최대한 줄여야 한다.

Fig. 1. 
Comparison of task execution models

멀티코어에서 동시에 메모리 작업을 요청하는 동작을 방지하기 위해서 TDMA 실행 모델이 제안되었다[10][11]. TDMA는 그림 1의 (b)와 같이 각 코어에서 실행되는 태스크들의 실행이 병렬적으로 수행되지 않고 한 번에 하나의 코어의 태스크만 실행한다. 이를 통해 각 코어의 태스크에서 메모리 접근이 발생하더라도 하나의 태스크만 실행되고 있으므로 코어 간 간섭이 발생하지 않는다. 하지만 하나의 코어의 태스크만 실행되므로 멀티코어 시스템의 처리량이 저하되는 문제가 발생한다.

멀티코어에서 TDMA 실행 모델 적용에 따른 처리량 저하와 같은 문제를 해결하기 위해 3-Phase 실행 모델이 제안되었다[12][13]. 3-Phase 실행 모델은 태스크를 메모리 읽기(Am Acquisition), 실행/연산(E, Execution), 메모리 쓰기(R, Restitution)의 3단계로 구분해 실행한다.

A 단계에서는 메모리에 접근해 데이터를 가져오며, E 단계에서는 앞선 A 단계에서 가져온 데이터를 바탕으로 연산한다. 이후 R 단계에서 E 단계의 연산 결과를 메모리에 저장하는 작업을 수행한다. 이때, A와 R 단계에서는 캐시 미스로 인한 태스크 실행 시간 예측성 감소를 줄이기 위해 각 코어의 캐시(L1 캐시) 크기보다 작은 크기로 데이터 읽기, 쓰기 작업을 수행한다. 또한 A와 R 단계는 메모리에 접근하므로 다른 코어에서 실행되는 태스크의 A, R 단계와 동시에 실행되지 않는다. 반면 E 단계는 이미 가져온 데이터로 연산해서 다른 태스크의 A, R 단계와 동시에 수행될 수 있다. 이러한 부분을 통해 멀티코어에서 동시적인 메모리 접근을 없애 코어 간 간섭을 줄이고 TDMA 보다 시스템의 처리량을 높일 수 있다. 하지만 TDMA에 비해 각 코어의 캐시 크기보다 작은 단위로 메모리에 접근하므로 반복적인 실행으로 전체적인 실행 시간은 증가할 수 있지만 간섭을 줄여 RTOS의 스케줄링 예측성을 증가시킬 수 있다.

하지만 3-Phase 실행 모델로 태스크를 동작시키기 위해서는 기존의 태스크 코드를 A, E, R 단계에 맞춰 수정하거나, 별도의 스케줄러가 필요할 수 있다. 본 논문에서 제안한 지연 가능 AER 실행 모델은 기존의 3-Phase 실행 모델과는 다르게 각 태스크의 R 단계를 지연시켜 동시에 실행한다. 태스크를 3-Phase 모델로 실행하기 위해 태스크를 A, E, R 단계로 나눠서 구현하였고, 별도의 스케줄러 구현 없이 RTOS의 프로세스 간 통신 (IPC, Inter-Processor Communication) 중 이벤트를 사용해 각 단계의 실행을 제어하였다.

본 장에서는 본 논문에서 제안한 d-AER 실행 모델의 설명에 앞서 멀티코어에 발생할 수 있는 메모리 공유로 인한 코어 간 간섭에 대한 영향을 분석한다. 그림 2와 같이 ARM Cortex-A9 쿼드코어가 탑재된 SABRE Lite 보드에서 VxWorks 6.9 SMP(Symmetric Multiprocessing)를 사용해 실험을 수행하였다.

Fig. 2. 
Experiments environment

각 코어는 32KB의 인스트럭션 캐시와 32KB의 데이터 캐시를 가지며, 각 코어가 공유하는 1MB의 L2 캐시와 1GB의 메인 메모리가 존재한다.

메모리 공유로 인한 간섭 측정을 위해 그림 1의 (a)와 같이 VxWorks의 태스크를 코어별로 1개씩 생성해서 동시에 실행하였다. 각 태스크는 512KB 크기로 메모리 주소를 읽어서 값을 배열에 저장하는 작업을 수행한다. 메모리 동시 접근으로 인한 간섭을 확인하기 위해 동시에 실행되는 코어(태스크)의 개수를 1~4개로 변화시키면서 300회 반복해 태스크의 실행 시간(Cycle, 사이클)을 측정하였다.

그림 3은 실험 결과를 나타낸다. 1개의 코어만 사용하였을 때 평균적으로 1,464 사이클이 소요되었고 2개의 코어가 동시에 실행될 때는 약 1.1배 증가한 1,619 사이클이 소요되었다. 3개와 4개의 코어에서 동시에 태스크를 실행할 때 각각 약 1.4배 증가한 2,068 사이클, 2,065 사이클이 소요되었다.

Fig. 3. 
Memory access interference depending on the number of cores

실험을 통해 동시적인 메모리 접근으로 인해 간섭이 발생하여 실행 시간이 최대 1.4배까지 증가함을 확인하였다. 이에 따라 설정된 태스크의 마감 시간 내에 작업이 종료되지 못하는 문제가 발생할 수 있다.

본 논문에서는 기존에 제안된 3-Phase 실행 모델을 바탕으로 태스크의 일부 작업을 지연시켜서 동시에 실행하는 d-AER 실행 모델을 제안한다. 기존 3-Phase 실행 모델은 태스크를 A, E, R 단계로 나누어 각 코어에서 실행될 때 메모리에 접근하는 A와 R 단계가 동시에 실행되지 않도록 태스크를 실행한다. 하지만 본 논문에서 제안하는 d-AER 실행 모델은 그림 4와 같이 각 태스크의 R 단계를 지연시켜 모든 코어의 E 단계가 끝나고 동시에 실행한다.

Fig. 4. 
d-AER task execution model

제안한 d-AER 실행 모델에서 R 단계를 동시에 실행하는 것은 메모리에서 데이터를 읽어오는 작업과 쓰는 과정에서 발생하는 캐시 미스가 똑같은 영향을 미치지 않기 때문이다. 메모리 읽기 작업에서 발생하는 캐시 미스는 프로세서의 스톨(Stall)을 발생시키지만, 메모리 쓰기 작업은 일반적으로 임계 경로(Critical path)에 포함되지 않는다[14]. 따라서 이러한 점을 이용해 R 단계에서 발생하는 코어 간 간섭을 일부 수용해 시스템 전체의 처리량을 높여 실행 시간 감소를 목표로 한다. 하지만 본 논문에서 제안한 d-AER 실행 모델은 각각의 태스크 관점으로 보면 그림 4와 같이 코어 1~3의 경우 기존의 AER 실행 모델과 비교했을 때 태스크의 실행 시간이 증가할 수도 있는 한계점을 가진다.

d-AER 실행 모델의 구현을 위해 그림 5와 같이 4개의 코어에 각 1개의 태스크가 할당되고, 태스크의 코드는 A, E, R 단계로 구성되어 있다. 코어별 각 코어의 태스크는 코어 1부터 4까지 차례대로 실행되며 동일한 우선순위를 가지도록 설정하였다. 태스크의 A 단계(acquisition() 함수)는 메모리에 L1 캐시 이하의 데이터를 읽어와 지역 변수(배열)에 저장하고, E 단계(execution() 함수)에서는 덧셈, 곱셈 등의 임의 연산으로 배열의 값을 수정하고 R 단계(restitution() 함수)는 연산된 값을 다시 특정 메모리 주소에 저장한다. 각 태스크의 A, E, R 단계의 실행 제어를 위해 VxWorks 6.9의 IPC 기능 중 메시지 함수 eventSend(), eventReceive()를 사용하였다.

Fig. 5. 
Implementation of d-AER task execution model

코어 1의 태스크가 실행되기 전까지 다른 태스크는 eventReceive() 함수를 사용해 대기한다. 코어 1의 A 단계가 종료되면 코어 2에 eventSend() 함수를 통해 이벤트를 전송하고, 코어 2는 eventReceive() 함수가 이벤트를 받아서 A 단계를 실행한다. 이때 코어 1은 E 단계를 실행하고 eventReceive() 함수를 통해 대기를 한다. 이와 같은 과정을 코어 4의 E 단계 실행까지 반복하고, E 단계가 종료되면 모든 코어의 태스크에 eventSend() 함수를 사용해 이벤트를 전송한다. 이후 코어 1~4의 R 단계가 동시에 실행되고 종료 이후 다시 eventReceive() 함수를 사용해 실행을 대기한다.