이벤트 트레이스(Event Trace)를 통한

이 글에서는 우선 순위 할당이 시스템 성능에 어떤 영향을 미치는지 살펴보고, 고유 우선순위 사용이 사실상 어떻게 오버헤드를 늘리고, 전반적인 처리량을 줄일 수 있는지 살펴보고자 한다.
글: 윌리엄 E. 라미(William E. Lamie)/ 익스프레스 로직(Express Logic) 자료제공: ARM(www.arm.com)
우선순위  할당의 영향을 측정하기 위해서 두 사례를 가정해보았다. 한 가지는 모든 쓰레드가 동일 우선순위를 부여 받는 경우이고, 나머지는 각 쓰레드가 고유 우선순위를 갖는 것이다.
사례 1: 모든 쓰레드가 동일한 우선 순위를 갖는다. (A=4, B=4, C=4, D=4)
사례-1에서 각 쓰레드에 우선순위 4를 할당하였다. 모든 쓰레드가 동일한 우선순위를 가질 때는 만들어진 순서대로 (A, B, C, D) 라운드 로빈 방식으로 실행될 것이다. 그림 6의 실행 이벤트 트레이스는 쓰레드 D가 메시지 큐를 다 채우고 나서 본 사례가 어떻게 운영되는 지를 보여준다. 쓰레드 A, B, C는 각각 자신의 큐에서 3개의 메시지를 회수하며, 그리고 나서 추가 메시지를 기다리며 정지 상태로 들어간다. 쓰레드 3개 모두가 다 실행되고 나면, 쓰레드 D가 다시 실행되어 추가로 3개 메시지를 각 큐에 채우게 되고, 이 시퀀스가 계속해서 반복된다.
(그림 6. 사례 1의 이벤트 트레이스: 동일한 우선순위. 본 그림은 쓰레드 A, B, C가 각각 3개의 메시지를 회수하고 나서 쓰레드 D가 각 쓰레드에 추가로 3개의 메시지를 보내는 것을 보여준다. 이 사이클이 계속해서 반복된다.)
쓰레드 A, B, C는 각각 자신의 메시지 큐에서 3개 메시지를 읽는다. 'QR' (queue read) 이벤트는 큐에서 하나의 메시지가 성공적으로 읽혀졌다는 것을 의미한다. 3개 메시지를 모두 읽은 다음 큐가 비게 되면, 해당 쓰레드는 정지되고 쓰레드 D가 추가로 메시지를 보내기를 기다린다. 'IS'(internal suspend) 이벤트는 RTOS가 쓰레드를 정지하고, 라운드 로빈 방식으로 다음 쓰레스로 컨텍스트 스위치를 개시하는 스케줄러로 돌아간다는 것을 의미한다. '생산자' 역할을 하는 쓰레드 D는 결국 실행이 되고 추가로 메시지를 큐에 보낸다('QS' 이벤트에서 나타난 것처럼). 쓰레드 D가 처음 3개 메시지를 각각 전송할 때마다('QS' 이벤트에서 제시된 것처럼) 'IR'(Internal Resume) 이벤트가 발생한다는 것에 주목하라. IR 이벤트는 메시지를 기다리던 쓰레드가 실행 할 '준비가 되었'지만, 라운드 로빈 시퀀스에 따라 자신의 차례를 기다려야만 한다는 사실을 나타낸다. 3번째 메시지가 전송되고 나서(각각 기다리는 쓰레드에 하나씩) 아직 회수되지 않은 첫 메시지에 의해 이미 쓰레드가 재개되었기 때문에('준비가 되었기') 후속 메시지는 추가로 IR을 일으키지 않는다.
이 경우 한 개 쓰레드가 자신의 프로세싱을 완료할 때 마다(프로세싱은 큐에 메시지가 들어오기를 기다리면서 정지되거나 쓰레드 D의 경우는 메시지를 전송하고 나서 완료가 된다) 정확하게 한 번의 컨텍스트 스위치가 일어나기 때문에 다음 차례의 쓰레드가 실행될 수 있다. 그 결과 쓰레드 A가 쓰레드 D가 보낸 첫 번째 메시지를 회수하는 한 '사이클' 당 총 4번의 컨텍스트 스위치가 일어난다. 그림 6에서 하나의 애플리케이션 사이클의 시작(Start) 및 중지(Stop) 경계를 살펴보라. 시작과 중지 간의 컨텍스트 스위치 수가 합계가 되어 총 4번이 그림 7의 상단 우측에 포개진 '성능 통계(performance Statistics)' 디스플레이에 반영되어 있다.
(그림 7. 사례1의 컨텍스트 스위치 수. 9개의 메시지가 전송 및 수신되는 한 번의 사이클을 완성하는데 단지 4개의 컨텍스트 스위치만이 필요하다는 점을 기억하라. 이 그림은 다양한 RTOS 작업의 수를 보여준다.)
(그림 8. 사례-2의 프로세싱 흐름. 이 경우 쓰레드 D가 각 메시지를 전송한 후 선제조치가 발생하고 제어가 즉각적으로 해당 메시지를 기다리고 있는 쓰레드로 전송된다는 점에 주목하라.)
사례-1, 9개 메시지가 전송되고, 9개 메시지가 수신되었으며, 4번의 컨텍스트 스위치가 일어난다. 사례-2: 모든 쓰레드에 고유 우선순위가 부여된 경우
사례-2에서는 각 쓰레드에 고유 우선순위가 할당된다. 쓰레드 A=1, 쓰레드 B=2, 쓰레드 C=3 그리고 쓰레드 D=4. 모든 쓰레드가 고유 우선순위를 가지고 있기 때문에 실행 준비가 된 가장 높은 우선순위의 쓰레드가 RTOS에 의해 실행된다. 그림 8은 사례-2의 이벤트 시퀀스를 보여준다.
위 그림 8은 쓰레드 D가 메시지를 쓰레드 A에 보내고 나서 즉각적으로 반복해서 발생하는 프로세싱 기간을 보여준다. 여기서 우리가 확인할 수 있듯이 쓰레드 D가 메시지를 전송 할 때 사례-1과 마찬가지로 이는 즉각적으로 IR(Internal Resume) 이벤트를 일으킨다. 그러나 사례-1과 달리 사례-2에서는 메시지를 기다리는 모든 쓰레드가 쓰레드 D보다 우선순위가 높기 때문에 메시지를 수신하는 쓰레드가 실행 준비가 된 우선순위가 가장 높은 쓰레드가 된다. 그 결과 RTOS는 쓰레드 D를 선점하고 쓰레드 D에 컨텍스트 스위츠를 수행한다. (그림 9에 나타난 컨텍스트 스위치 #2,4,6,8,10,12,14,16 그리고 18)
이는 메시지를 기다리는 쓰레드의 우선순위가 쓰레드 D와 같았기 때문에 쓰레드 D가 큐에 메시지를 전송할 때 선제조치가 일어날지 않았던 사례 1의 이벤트와는 다르다. 여기서 각 쓰레드가 큐에서 메시지를 회수하고 나면('QR' 이벤트), 쓰레드는 다시 정지 상태로 들어가 다음 메시지를 기다리고 ('IS(Internal Suspend) '이벤트에서 나타난 것처럼) RTOS는 다시 한 번 더 쓰레드 D에 컨텍스트 스위치(컨텍스트 스위치 #1,3,5,7,9, 11,13,15 그리고 17)를 실시한다.
사례-2에서도 사례 1과 똑같이 9개의 메시지가 전송되고, 9개의 메시지가 회수된다. 그러나 사례-1에서 4번의 컨텍스트 스위치가 일어난 것과는 달리 사례-2에서는 동일한 9개 메시지를 처리하는데 컨텍스트 스위치가 18번 발생하여 350% 늘어난다. 이는 단지 4번의 컨텍스트 스위치만 발생한 사례 1 (그림 7)과 비교하여 위 그림 9에 표시된 쓰레드 A에 해당하는 두 개의 'QR' 이벤트 사이에서 확인할 수 있다.
(그림 9. 사례-2에 완벽한 사이클을 위한 스위치. 증가하는 RTOS 이벤트 수가 입력되는 것에 주목하라.)
쓰레드를 준비시키는 쓰레드 보다 그것에 의해 준비가 되는 쓰레드의 우선순위가 더 높은 사례-2의 고유 우선순위 할당 전략은 사례-1에 적용된 것과 같은 쓰레드 동일 우선순위 할당 방법에 비해 컨텍스트 스위치 발생 수가 현격하게 늘어나는 결과를 가져온다.
쓰레드 우선순위 선정에 따라 똑같은 애플리케이션에 최적의 우선순위 조건에 비해 거의 다섯 배나 많은 수의 컨텍스트 스위치가 발생할 수 있다.
(그림 10. 고유 우선순위가 작업에 할당되는 경우 컨텍스트 스위치가 350% 늘어나 시스템의 효율성이 현격하게 떨어진다.)
(그림 11. 사이클 시작(Cycle Start) 및 사이클 종료(Cycle End) 이벤트 타임 스탬프는 한 사이클 완료에 걸리는 시간을 나타낸다. 사례-1(동일 우선순위)은 왼쪽에 사례-2(고유 우선순위)는 오른쪽에 제시되었다.)
(그림 12. 시간 측정을 통해 고유 우선순위 경우 오버헤드가 상당히 늘어남을 알 수 있다.)
사례-2, 9개 메시지 전송, 9개 메시지 회수 그리고, 18번의 컨텍스트 스위치 발생.
시간 분석
물론, 고유 우선순위 사용으로 인해 컨텍스트 스위치 수가 추가로 늘어남에 따라 발생하는 주된 영향은 이 늘어난 컨텍스트 스위치로 인해 RTOS 오버헤드가 증가하는 것이다. 늘어난 컨텍스트 스위치로 인한 추가 오버헤드를 측정하기 위해서 우리는 사이클-경계 양보(relinquish) 이벤트 간의 클럭 카운트 차이를 측정했다. 각 이벤트에는 시스템 클럭에서 찍힌 고유한 타임 스탬프가 있으며 다음 RO 타임 스탬프에서 'RO' 타임 스탬프를 하나를 빼면 해당 사이클에 대한 경과 시간을 얻을 수 있다. 사례-1에서 200MHz 또는 5.12ms 속도에서 틱(tic)이 1024번 있었다. 사례-2에서는 9.30ms에서 1861번의 틱이 발생했다. 사례-2에서는 늘어난 컨텍스트 스위치와 고유 우선순위 사용으로 인해 발생한 선제조치로 애플리케이션의 오버헤드가 증가하였다.
이 시간 실험에서 우리는 CPU를 200 MHz로 실행하고 아트멜(Atmel) AT91S AM9263-EK 보드를 사용했다. 이 시스템에서 ThreadX RTOS는 0.35ms라는 매우 빠른 속도로 컨텍스트 스위치를 일으킨다. 그러나 고유 우선순위 사용으로 인한 컨텍스트 스위치 오버헤드의 증가로 사용된 RTOS에 따라 사실상 컨텍스트 스위치 당 최대 250ms까지 시간이 늘어날 수 있다. 그 결과가 그림 12와 같이 확인되었다.
견해
이 실험은 사례-2에서는 동일한 수의 메시지가 전송되고 수신되었음에도 14번의 추가 컨텍스트 스위치가 실행되고, 총 프로세싱 시간이 80% 이상 증가했다는 것을 보여준다. 만약 본 예시에서 컨텍스트 스위치 작업이 0.35ms의 속도로 빨리 이루어지지 않았다면, 총 프로세싱 시간에 미치는 영향은 더욱 컸을 것이다. 각 애플리케이션 쓰레드에 대해 고유 우선순위를 할당한 결과 RTOS 오버헤드가 80% 증가되고, 그에 따라 시스템 처리량이 감소한 것으로 나타났다.
또한, 고유 우선순위 사용은 시스템의 성능에 대한 예측성을 떨어뜨릴 수도 있다. 예측성이 떨어지는 이유는 우선순위가 동일한 쓰레드에 사용되는 라운드 로빈 스케줄링처럼 정해진 방식으로 이루어지기 보다는 쓰레드의 활성화 시퀀스 결과로 인해 컨텍스트 스위치 오버헤드가 다양하게 나타나기 때문이다.
개발자는 특정 작업 양을 수행하기 위해서는 항상 일정한 수의 컨텍스트 스위치가 일어나야만 하기 때문에 다중 쓰레드에 동일한 우선순위를 할당함으로써 이러한 예측불가능을 제거할 수 있다. 만약 다른 우선순위가 각각의 쓰레드에 할당된다면, 애플리케이션 개발자는 시스템 성능 및 대응성에 차이가 발생할 수 있다는 가능성을 예리하게 인식할 필요가 있다.
고유 우선순위를 사용하는 경우
고유 우선순위를 사용하면 다중 쓰레드를 동일 우선순위로 운영하는 것과 비교하여 컨텍스트 스위치 수가 늘어나고, 처리량이 저해되는 결과가 발생하기는 하나 어떤 경우에는 고유 우선순위를 사용하는 것이 적절하기도 하다. 예를 들어, 앞선 예시에서 지연이 처리량보다 더 중요하다고 한다면 우리는 쓰레드 A가 라운드 로빈 방식에 따라 자신의 차례를 기다리기 보다는 메시지가 큐에 도착하는 즉시 실행되기를 바랄 것이다.
(그림 13. 메시지 프로세싱 지연과 메시지 처리량 간의 절충을 보여주는 표. 고유 우선순위할당방식은 지연을 줄여주는 반면 동일 우선순위할당방식은 처리량을 높여준다.)
그러한 결과를 이끌기 위해 쓰레드 D보다 쓰레드 A에 높은 우선순위를 할당하게 될 것이며, 쓰레드 B와 쓰레드 C도 마찬가지이다. 이 경우, 지연은 낮출 수 있을 테지만 그림 13의 표에 제시된 것처럼 처리량이 밀리세컨드 당 1740메시지에서 960메시지를 줄어드는 것을 감수해야 한다.
우선순위 상속(priority inheritance) 및 시간 분할
개발자들이 쓰레드 우선순위 선정으로 인해 발생하는 어느 정도 불확실한 컨텍스트 스위치 오버헤드 문제를 처리할 수 있는 가장 좋은 방법은 동일한 우선 순위 레벨에 가능한 많은 쓰레드를 유지하는 것이다. 다시 말하자면, 지연이 처리량 보다 더 중요하고, 선제 조치가 절대적으로 필요할 때만 상이한 우선순위 레벨을 사용하고 다른 경우에는 절대 사용하지 않는 것이다. 특히, 동일한 우선순위로 다중 쓰레드를 운영하게 되면 우선순위 상속, 라운드 로빈 스케줄링, 시간 분할 등 다른 시스템 요건도 적절하게 처리할 수 있다. 이러한 메커니즘은 모두 실시간 시스템에서 중요하며, 시스템 오버헤드를 낮추는데 모두 활용할 수 있으며, 더 중요한 점은 이러한 메커니즘을 통해 시스템 거동을 이해할 수 있다는 것이다.
우선순위 상속은 RTOS가 우선순위 역전의 경우 교착상태를 예방하기 위해 사용하는 메커니즘이다. 우선순위 역전은 우선순위가 낮은 쓰레드가 우선순위가 높은 쓰레드가 필요로 하는 자원을 소유하고 있지만, 우선순위가 낮은 쓰레드가 두 쓰레드 중간의 우선순위를 가진 다른 쓰레드에 의해 선점되었을 때 발생한다.
그리하여 낮은 우선순위의 쓰레드는 그보다 우선순위가 높은 쓰레드에 의해 선점되었기 때문에 실행 할 수 없으며, 낮은 우선순위의 쓰레드가 가지고 있는 자원을 분리할 수가 없다. 높은 우선순위의 쓰레드는 낮은 우선순위의 쓰레드가 자원을 풀어 놓을 때까지 기다리게 되어 사실상 높은 우선순위 쓰레드가 교착상태에 빠지게 된다.
우선순위 상속을 통해 낮은 우선순위의 쓰레드는 일시적으로 자원을 기다리고 있는 높은 우선순위 쓰레드의 우선순위를 취할 수 있다. 그렇게 되면, 낮은 우선순위 쓰레드는 자원을 떼어 놓을 수 있는 지점까지 실행 할 수 있으며, 그러면 높은 우선순위 쓰레드는 자원을 확보하고 실행하게 된다. 만약 모든 쓰레드가 고유 우선순위를 가져야만 하는 상황이라면, 우선순위가 낮은 쓰레드는 자원을 기다리는 쓰레드의 우선순위가 이미 사용 중이기 때문에 그것의 우선순위를 취할 수가 없다. 마찬가지로 특정 우선순위에 사용할 수 있는 쓰레드 수에 제한이 있는 경우, 해당 우선순위에 이미 들어갈 수 있는 최대 수의 쓰레드가 있다면, 우선순위가 낮은 쓰레드가 우선순위가 높은 쓰레드의 우선순위 레벨까지 올라가는 것은 불가능하다. 만약 한 우선순위가 할당될 수 있는 쓰레드 수가 1로 제한되어 있다면, 우선순위 상속은 절대 불가능하며 우선순위 역전을 해결하기 위해 다른 해결책을 찾아야만 한다.
라운드 로빈 스케줄링은 RTOS가 순환 방식으로 쓰레드를 실행하여 각 쓰레드가 '차단'되거나 자신의 차례를 양도할 때까지 실행할 수 있도록 한다. 다시 말하자면, 우선순위가 높은 쓰레드에 의해 선점되는 쓰레드가 없다. 라운드 로빈 스케줄링을 통해 여러 개의 똑같이 중요한 활동을 동일한 우선순위에서 실행하면서도 여전히 개별 캡슐화를 유지할 수 있다. 이 방법은 위에서 우리가 예로 든 4개의 쓰레드가 4의 우선순위를 가지고 우선순위가 높은 쓰레드에 의해 선점당하지 않고 시퀀스로 운영되는 사례-1에서 사용되었다.
시간 분할은 가중 방식으로 여러 쓰레드에 CPU 사이클을 분배하는 RTOS 스케줄링 방식이다. 가장 일반적으로 시간 분할은 동일 우선순위 레벨의 쓰레드에 특정 수의 CPU 사이클을 할당하는데 사용되어, 한 쓰레드에서 다음 쓰레드로 순환하고, 그리고  쓰레드가 액티브 상태로 있는 한 계속해서 다시 그룹의 처음으로 돌아간다. 또한, 시간 분할은 CPU 시간을 비율적으로 각 쓰레드에 할당하는데도 사용할 수도 있다. 예를 들어, 해당 우선순위가 액티브한 동안 쓰레드 A에는 25%, 쓰레드 B에는 10%, 쓰레드 C에는 10% 그리고 쓰레드 D에는 55%의 CPU 사이클을 할당하는 것이다. 이는 일반적으로 자의적인 CPU 사이클 수('블록(block)')를 비율적으로 나누면 가능하다. 본 예에서 쓰레드 A는 250개 사이클을, 쓰레드 B는 100개 사이클을, 쓰레드 C는 100개 사이클을, 쓰레드 D는 550개 사이클을 수행하고 다시 쓰레드 A로 돌아와서 250개 사이클을 수행하는 식으로 1000개의 사이클 블록을 사용할 수 있을 것이다(예: 200MHz 시스템에서 5ms). 이러한 할당 방식을 통해 시스템 설계자들은 더 많은 작업을 요하는 쓰레드에 시간을 더 제공하면서도, 동일 우선순위의 다른 쓰레드를 선점하지 않도록 만들 수 있다.  
결론
여러 쓰레드에 동일한 우선순위를 할당하는 방식은 많은 이점이 있으며, 시스템 설계자들이 실시간 시스템의 적절한 운영을 위협하는 함정을 피할 수 있도록 도와준다. 특히, 이 방식으로 오버헤드를 줄이고, 처리량을 늘릴 수 있으며, 우선순위 유산과 시간 분할 스케줄링 방법도 적용할 수 있다.
개발자는 다른 우선순위는 가능한 적게 사용하고, 진정으로 선제조치가 필요한 경우에만 고유 우선순위를 사용하는 것이 바람직하다. 많은 RTOS는 두 가지 우선순위 할당 방법을 모두 제공하기는 하지만, 일부는 특정 우선순위에 사용할 수 있는 쓰레드 수에 제한을 두고 있다. 이에 그치는 것이 아니라, 일부 RTOS는 특정 우선순위에서 한 개의 쓰레드 사용만 허용하기 때문에 이러한 RTOS로는 처리량이 우수한 라운드 로빈 스케줄링 방식을 지원할 수 없거나 우선순위 상속을 적절하게 실행할 수 없다.
개발자가 동일한 우선순위에 다중 쓰레드 할당을 지원하지 않는 RTOS의 한계를 이해하고, 이러한 인식 하에 RTOS를 선정하는 것이 중요하다.<출처: IQ 매거진 Volume 8, Number 1, 2009년 3월호>
회원가입 후 이용바랍니다.
개의 댓글
0 / 400
댓글 정렬
BEST댓글
BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
/ 400
내 댓글 모음
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지