工學碩士學位請求論文

인터럽트인터럽트인터럽트인터럽트 지연지연지연지연 시간의시간의시간의시간의 감소를감소를감소를감소를 통한통한통한통한

BrickOSBrickOSBrickOSBrickOS 의의의의 실시간성실시간성실시간성실시간성 강화에강화에강화에강화에 관한관한관한관한 연구연구연구연구

A SA SA SA Study ontudy ontudy ontudy on Enhancement of Enhancement of Enhancement of Enhancement of BrickOSBrickOSBrickOSBrickOS’’’’s Rs Rs Rs Realealealealtime time time time

CCCChahahahararararacteristic cteristic cteristic cteristic by Reducing by Reducing by Reducing by Reducing Interrupt LInterrupt LInterrupt LInterrupt Latencyatencyatencyatency

2007 年 2 月

仁荷大學校 大學院

情報通信工學科

河 正 大

工學碩士學位論文

인터럽트인터럽트인터럽트인터럽트 지연지연지연지연 시간의시간의시간의시간의 감소를감소를감소를감소를 통한통한통한통한

BrickOSBrickOSBrickOSBrickOS 의의의의 실시간성실시간성실시간성실시간성 강화에강화에강화에강화에 관한관한관한관한 연구연구연구연구

A Study on Enhancement of BrickOSA Study on Enhancement of BrickOSA Study on Enhancement of BrickOSA Study on Enhancement of BrickOS’’’’s Realtime s Realtime s Realtime s Realtime

Characteristic Characteristic Characteristic Characteristic by Reducing Interrupt by Reducing Interrupt by Reducing Interrupt by Reducing Interrupt LatencyLatencyLatencyLatency

2007 年 2 月

指導敎授 吳 範 渙

이 論文을 碩士學位論文으로 提出함

仁荷大學校 大學院

情報通信工學科

河 正 大

이 論文을 河正大의 碩士學位論文으로 認定함.

2007 年 2 月 日

主審 印

副審 印

委員 印

i

요요요요 약약약약

임베디드 시스템인 RCX에 탑재된 BrickOS(Brick Operating System)는

실시간 태스크 수행 중 두 가지의 지연 요소를 가진다. 첫번째 지연은 실시간

태스크가 생성되어 실제 수행에 들어가는 과정중에 발생한다. 이는 실시간

태스크는 실행할 준비가 되어 있지만 라운드 로빈 방식에 의해 다음 타임

퀀텀까지 기다려야 하는 지연이다. 두번째 지연은 스케줄링 알고리즘에 의해

발생한다. 실시간 태스크가 수행 중일때 호출되는 스케줄러는 특별한 경우를

제외하고는 의미가 없다. 때문에 실시간 태스크의 수행중 호출 되는

스케줄러는 그 자체로 지연 시간이 된다. 이에 본 논문에서는 위의 두 지연을

해소하기 위해 스케줄러의 호출 방식에 변화를 주었다. 매 일정한 타임

간격마다 스케줄러를 호출하는 대신 타이머 인터럽트가 발생할 때마다

스케줄러의 호출 여부를 결정한다. 이를 통해 첫번째 지연을 감소 시킬 수

있다. 그리고 두번째 지연을 해결하기 위해 매 순간마다 실시간 태스크의

생성 여부와 실행 여부를 체크하도록 하였다. 이는 스케줄러의 필요성을

판별하기 위한 방법으로 이를 통해 스케줄러의 호출을 제한함으로서 두번째

지연을 감소시킬 수 있다. 본 논문에서는 위에서 제안하는 알고리즘을

BrickOS의 커널 분석과 수정, 추가등을 통해 구현하는 과정을 보인다. 그리고

비교 실험을 통해 제안 된 알고리즘에서 동작하는 실시간 태스크의 수행에 약

8%의 성능 향상이 있음을 보인다.

ii

Abstract

BrickOS(Brick Operating System) on top of RCX system has two latency

factors against real-time characteristic. The first one happens between the

real-time task’s creating and beginning. When the operating system tries

to start real-time job it couldn’t start instantly. Because it has to wait

until next time tick is over. So the latency can happen. Next lantency

happens by BrickOS’s scheduling algorithm. BrickOS tries to call the

scheduler every time tick. But it is useless to call the scheduler while the

real-time task is running. The reason is that it is impossible for any normal

task to take CPU when the real-time task is running. Therefore, in that

case calling the scheduler can be latency. To solve this latency problem,

this paper suggests new scheduler calling method. Timer interrupt handler

checks if new real-time task is made or not. If it is, they call the scheduler.

This method calls the scheduler faster than original calling way. Timer

handler also checks if there is a running real-time task. And it has any

actions if there is. This means that there is no scheduler calling if any

real-time task is running. So we can save more time to process the real-

time task. This paper shows the process of implementation this algorithm

in BrickOS through the kernel analysis and modification. And it also shows

that the real-time task in the implemented system is 8% faster than the

origin one by experiments.

iii

목목목목 차차차차

제제제제 1 1 1 1 장장장장 서서서서 론론론론 ...............................................................................1

제제제제 2 2 2 2 장장장장 관련관련관련관련 연구연구연구연구 ........................................................................3

2.1 MindStorm 및 RCX의 소개 .................................................................... 3

2.2 BrickOS kernel ....................................................................................... 4

2.2.1 Kernel의 시작................................................................................... 4

2.2.2 kernel의 동작구조 ............................................................................ 5

2.2.2 메모리 관리 ...................................................................................... 5

2.2.3 Networking....................................................................................... 7

2.3 실시간 스케줄링 ...................................................................................... 7

2.3.1 실시간 스케줄링 알고리즘의 개념.................................................... 7

2.3.2 정적 우선순위 스케줄링 ................................................................... 8

2.3.3 동적 우선순위 스케줄링 ................................................................. 10

제제제제 3 3 3 3 장장장장 BrickOS BrickOS BrickOS BrickOS 스케줄링의스케줄링의스케줄링의스케줄링의 문제점과문제점과문제점과문제점과 개선방안개선방안개선방안개선방안 ...................... 12

3.1 BrickOS의 스케줄링 기법 ..................................................................... 12

3.1.1 라운드 로빈 스케줄링 기법 ............................................................ 12

3.1.2 우선 순위 기반의 선점형 스케쥴링 ................................................ 14

3.2 기존 스케줄링의 문제점........................................................................ 19

3.2.1 태스크 생성부터 선점 사이의 지연 ................................................ 19

3.2.2 불필요한 스케줄러의 호출에 따른 지연 ......................................... 20

3.3 개선된 실시간 스케줄링........................................................................ 22

3.3.1 개선된 실시간 스케줄링 알고리즘.................................................. 22

3.3.2 개선된 실시간 스케줄러의 구현 ..................................................... 25

제제제제 4 4 4 4 장장장장 실험실험실험실험 및및및및 결과결과결과결과 ................................................................ 29

4.1 실험 환경 .............................................................................................. 29

4.2 실험 및 결과 ......................................................................................... 30

제제제제 5 5 5 5 장장장장 결론결론결론결론 .............................................................................. 34

1

제제제제 1 1 1 1 장장장장 서서서서 론론론론

오늘날 다양한 임베디드 시스템에서 실시간 처리 기능에 대한 요구가 날로

높아지고 있다. 임베디드 시스템인 RCX의 기본 펌웨어를 대체하는

BrickOS(Brick Operating System) 역시 실시간 서비스를 제공하기 위해 우선

순위 기반의 라운드 로빈 방식의 스케줄링 방식을 채택하고 있다[1,2]. 라운드

로빈 스케줄링 방식은 태스크의 기아상태(starvation)을 해소해 주지만 완료

시간에 대한 고려를 전혀 하지 않기 때문에 태스크의 작업 완료에 있어

최선의 노력을 해야 하는 실시간 시스템에는 적합하지 않은 알고리즘이다.

실시간 태스크를 수행하는 데 있어 BrickOS의 스케줄링 방식에는 두 가지의

지연 요소가 생긴다. 첫번째 지연은 실시간 태스크의 생성에서 실제 수행에

들어가는 과정중에 발생한다. 실시간 태스크가 생성되어 실행할 준비를

끝마친 상황에서 태스크 선점을 하기 위해 다음 스케줄러의 호출까지

기다려야 한다. 이는 최대 타임 간격만큼 실시간 태스크의 수행이 지연 될 수

있다는 것을 의미한다. 매 일정한 간격으로 호출 되는 스케줄러 역시 그

자체로 지연이 될 수 있다. 실시간 태스크는 항상 최우선 순위를 가지고

수행이 된다. 따라서 수행중인 실시간 태스크가 다른 일반 태스크에 의해

선점이 되거나 스위칭이 되는 경우는 실제 스케줄러의 호출 횟수만큼

빈번하게 일어나지 않는다. 따라서 기존 알고리즘에 의해 호출되는

스케줄러는 특별한 경우를 제외하고는 의미가 없기 때문에 주기적으로

호출되는 스케줄러 자체가 태스크 수행의 지연을 의미한다.

이에 본 논문에서는 위의 두 지연을 해소하기 위해 스케줄러의 호출 방식에

변화를 주었다. 매 일정한 타임 간격마다 스케줄러를 호출하는 대신 타이머

2

인터럽트가 발생할때마다 스케줄러의 호출 여부를 결정하도록 하였다. 이는

태스크의 시작 시간을 앞당길 수 있기 때문에 첫번째 지연을 감소 시킬수

있다. 두번째 지연을 해소하기 위해서 매 타이머 인터럽트마다 실시간

태스크의 생성 여부와 실행 여부를 체크하도록 하였다. 이는 스케줄러의

필요성을 판별하기 위한 방법으로 이를 통해 스케줄러의 호출을 제한함으로써

두번째 지연을 감소시킬 수가 있다. 본 논문은 위에서 제안하는 알고리즘이

BrickOS의 커널 분석과 수정, 추가등을 통해 구현 되는 과정을 보이고 실험

결과를 통해 본 논문에서 제안한 실시간 시스템이 기존의 시스템에 비해

향상된 실시간 태스크 수행 능력을 가지고 있다는 것을 보여준다.

본 논문의 구성은 다음과 같다. 제2장에서는 관련연구들을 소개한다. 우선

BrickOS의 커널에 대해 소개하고, 그 다음으로 현재 연구되고 있는 실시간

스케줄링에 대해 알아본다. 제3장에서는 BrickOS의 스케줄링에서 발생하는

지연과 그에 따른 문제점을 알아보고 이를 해결하는 대안을 제시, 구현한다.

제4장에서는 실험을 통해 제안된 알고리즘의 성능 향상 결과를 보이며,

마지막 제5장에서는 결론 및 향후 연구방향에 대해 설명하고 끝을 맺는다.

3

제제제제 2 2 2 2 장장장장 관련관련관련관련 연구연구연구연구

BrickOS의 커널에 대해 알아보기 전에 실제 구현에 사용 되었던 통합 개발

킷인 MindStorm과 그 중 BrickOS를 탑재할 수 있는 임베디드 시스템인 RCX

에 대해 간략하게 알아본다.

2.1 2.1 2.1 2.1 MindStormMindStormMindStormMindStorm 및및및및 RCXRCXRCXRCX의의의의 소개소개소개소개

Lego MindStorm Kit은 여러가지 레고(Lego) 블록들과 바퀴, 기어, 모터, 터

치(Touch)센서, 빛센서, 적외선 통신이 가능한 컴퓨터 블록(RCX)을 포함하고

있는 통합 개발 킷이다. RCX에는 프로그래밍이 가능하여, 사고(思考)가 가능하

다. 즉, 여러가지 레고 블럭들을 컴퓨터 블록(RCX)과 연결하고 적당한 프로그

래밍만 해준다면, 로봇이 된다[1,2]. MindStorm은 기본적으로 window 환경에

서 동작하는 로봇 개발 환경을 제공하며 이는 GUI형식의 프로그래밍으로, 아

주 쉽고, 간단하며, 신속하게 RCX를 제어할 수 있는 프로그래밍을 할 수 있도

록 되어있다[3]. 그렇지만 MindStorm에서 제공하는 프로그래밍 환경에선 가

장 기본적인 제어만 제공하기 때문에 RCX를 보다 세밀하고 자유롭게 활용할

수 없다. 모터의 세밀한 조정 및 빛센서의 세밀한 감지도 불가능하며, RCX의

적외선 통신도 제어가 불가능하다. 따라서, RCX를 좀 더 완벽하게 활용할 수

있도록, 많은 사람들이 RCX 개발 환경을 개발하기 시작했다.

현재까지 개발된 RCX 개발 툴로는 프리소프트웨어(Free Software)인

NQC(Not Quite C)나 C언어를 통해 RCX를 개발할 수 있는 RCXCC와 legOS,

그리고 brickOS가 있다.[3] NQC나 RCXCC는 RCX에 들어있는 순정 펌웨어

(Firmware)를 바탕으로 동작하기 때문에, 순정 펌웨어의 능력을 넘는 제어는

불가능하다. 이에 비해 legOS와 그 차기 버전인 brickOS는 운영체제로, RCX

펌웨어를 교체한다. 따라서 운영 시스템 자체가 변경되고, 개발환경(gcc)이나

4

동작환경이 모두 바뀌어, RCX는 개선된 성능을 보인다[4]. 또한, 자체 통신

프로토콜을 사용하여 적외선 통신을 자유롭게 구현할 수 있어, RCX간의 통신

도 가능해진다.

본 연구에 사용된 하드웨어인 RCX는 Hitachi H8/3292 마이크로 컨트롤러

칩이 RCX제어의 대부분을 담당하는데, 이 칩에 내장되어 있는 구성 요소는

크게 H8/300 CPU와 MEMORY, Input/Output으로 나눌 수 있다. H8/300 CPU

는 10Mhz의 system clock으로 동작하며 8bit와 16bit 연산을 지원한다. RCX

에는 총 8개의 16bit레지스터(R0,R1,…R7)와 16bit 프로그램 카운트 레지스터

(PC), 8 bit condition code 레지스터(CCR)를 가지고 있다.[2] RCX에 사용되

는 메모리는 마이크로 컨트롤러 칩에 내장되어 있는 16Kbyte mask

programmable ROM과 512byte RAM 그리고 128byte의 온 칩 레지스터 필

드가 있으며 이와 별도로 32Kbyte의 외부 RAM이 있다. 그 외로 16bit 타이

머와 2개의 8bit 타이머 채널, A/D 컨버터와 I/O 포트들이 있다.

2.2 BrickOS kernel2.2 BrickOS kernel2.2 BrickOS kernel2.2 BrickOS kernel

2.2.1 Kernel의 시작

Kernel은 ROM에 의해 kmain 함수가 호출되면서 시작 한다. 이 함수는 싱글

태스킹이나 멀티 태스킹 모드로 들어가기 전 kernel의 초기화를 진행 한다.

만약 task manager가 kernel에 포함되어 있지 않다면 오직 싱글 태스크 모드

로만 작동하며 동적 프로그램 로딩은 불가능하게 된다. 이 논문에서는 task

manager가 동작 하며 멀티 태스킹 모드와 동적 프로그램 로딩을 지원 하도록

하였다. kernel이 초기화 되는 동안 시작되는 태스크는 3개이다. 첫번째는 아

5

무런 동작도 하지 않는 idle 태스크이며 나머지 두개는 동적 프로그램 로딩을

위한 packet_consumer 태스크와 key_handler 태스크이다. packet_consumer

태스크는 IR-port의 움직임을 제어하는 태스크로서 패킷의 송수신에 관한 일

을 한다. 그리고 key_handler 태스크는 RCX brick의 버튼에 대한 제어권을

가진 태스크로 버튼의 움직임에 대한 행동을 결정한다. 이 세가지 태스크가

생성된 후 task manager가 실행되며 태스크 스위칭을 시작한다.

2.2.2 kernel의 동작구조

kernel은 가장 먼저 메모리를 초기화하며, 그 외의 필요한 장치들을 초기화

한다. 시스템 타임을 초기화 힐때는 16비트 타이머에 1ms 마다 timer

interrupt이 발생하도록 하고, ROM 은 timer interrupt가 발생했을 경우

ocia_vector가 가리키는 systime_handler 함수를 호출 한다. systime_handler

함수는 다양한 서브 시스템들의 핸들러를 차례로 폴링하면서 실제적으로

BrickOS를 조종한다. 그리고 이러한 시스템은 BrickOS가 각각의 장치 환경들

과의 통신 수단으로 인터럽트를 쓰지 않고 폴링 방식을 사용한다는 것을 말한

다. systime_handler는 각각의 핸들러를 호출 하는 일 이외에도 일정한 타임

퀀텀이 지나면 tm_switcher라는 스케줄러를 호출하는 일을 통해 멀티 태스킹

을 가능하게 한다.

2.2.2 메모리 관리

BrickOS는 메모리 관리에 있어 순차적인 메모리 할당 방식을 사용하고 있다.

페이징이나 세그멘테이션과 같은 고급 메모리 관리 기법은 하드웨어에서 제공

6

해 주지 않고 있다. 만약 제공된다고 해도 매우 부족한 메모리 공간때문에 고

급 메모리 관리 방식은 오히려 더 많은 오버헤드를 발생 시킨다[5].

메모리는 커널 부분과 유저 부분으로 나누어저 있으며 커널 코드와 static 커

널 데이터는 0x8000부터 mm_start 주소 사이에 위치한다. 메모리 관리자는

mm_start 부터 0xFFFF까지의 모든 메모리를 관리한다. 기본적인 메모리 구

조는 [그림 2-1]과 같다.

[그림 2-1] 메모리 구조

7

2.2.3 Networking

BrickOS는 usb IR tower를 이용하여 외부와 통신을 한다. 통신 프로토콜로

LNP(LegOS Networking Protocol)[4]를 사용하며 Broadcast 성격의

Integrity 패킷과 특정 주소에만 전달하는 Addressing 패킷으로 나눌 수 있다.

패킷을 수신하게 되면, Receive Shift Register로 수신 데이터가 도착하게 되

고, 수신된 데이터가 이상 없다면, Receive Data Register로 수신 데이터가 옮

겨진다. Receive Data Register로 수신 데이터가 옮겨지면, RDR-FULL Flag의

Flip으로 인하여 인터럽트 처리기(ISR)가 발생해, Receive-end interrupt(RXI)

vector인 rx_handler를 호출하게 된다. rx_handler는 collision, checksum등을

계산하고, 패킷의 종류에 따라, Integrity 또는 Addressing Handler를 호출하

여, User에게 수신된 데이터를 전달한다.

패킷의 송신은 버퍼로 송신할 패킷을 복사한 후, Serial Control Register를

변경하여, Send interrupt vector인 tx_handler를 호출하여, 버퍼의 내용을 전

송하게 된다. BrickOS는 자신의 패킷이 아닐 경우에는 버리도록 되어있으므로,

다른 RCX로부터의 패킷 중계(Routing)가 불가능 하다.

2.3 2.3 2.3 2.3 실시간실시간실시간실시간 스케줄링스케줄링스케줄링스케줄링

2.3.1 실시간 스케줄링 알고리즘의 개념

실시간 스케줄링 알고리즘의 정의는 어떠한 자극에 대해 처리할 수 있는 시

간이 예측 가능하고 또한 완료 시간이 지켜져야 하는 일에 대해서 완료 시간

에 대한 보장을 해줄 수 있는 스케줄링 알고리즘을 의미한다. 여기서 중요한

사항은 “예측 가능”해야 된다는 것과 “완료 시간에 대한 보장”이 가능해야 된

8

다는 것인데 일반적인 리눅스나 윈도우즈 같은 범용 OS는 이러한 예측 가능

성과 완료 시간에 대한 보장을 해주지 못하기 때문에 실시간 OS로써 적합하

지 않다[6].

여기에는 soft real-time과 hard real-time으로 다시 분류될 수 있는 여지가

있므며, 대부분의 real-time class process들은 상용 시스템에서 완벽히 hard

real-time을 지원해 주고 있지는 못하다[7]. 완전한 hard real-time보다는

soft real-time을 지원한다는 말은 반드시 어떤 주어진 시간 안에는 마치지 못

하더라도 그 연산의 결과가 받아들일 만 하다고 여긴다는 말이다. 이 논문에

서 제안하는 알고리즘은 지연 시간의 감소를 통한 best effort service를 제공

한다. 즉 hard real-time 보다는 soft real-time의 요구를 만족시킨다.

또 다른 실시간 스케줄링 알고리즘의 분류 방법으로 정적 우선순위 스케줄링

(Static Priority Scheduling) 알고리즘과 동적 우선순위 스케줄링 (Dynamic

Priority Scheduling) 알고리즘으로 나누는 방법이 있다[8]. 정적 우선순위 스

케줄링 알고리즘은 우선순위가 한번 정해지면 변하지 않는 방식이며, 동적 우

선순위 스케줄링 알고리즘은 상황에 따라서 우선 순위가 변할수가 있다. 동적

우선순위 스케줄링 알고리즘은 스케줄링 당시의 상황에 따라 매번 우선 순위

를 계산하여야 하기 때문에 구현이 복잡하고 정적 스케줄링 알고리즘에 비해

많은 시간을 요구한다는 단점이 있으나 실제 모든 태스크의 실시간 제약을 만

족시키는 데에 있어서는 정적 스케줄링 알고리즘보다 보다 효율적이다.

2.3.2 정적 우선순위 스케줄링

정적 우선순위(Static Priority)는 태스크가 생성될 때, 최초로 정해지게 되고,

9

태스크 수행 중에는 바뀌는 경우가 생기지 않는다. 보통은 컴파일 시에 고정

된 값으로 주게 된다. 정적 우선순위 방식을 사용하는 스케줄링에는 Rate

Monotonic (RM) 과 DeadLine Monotonic (DM)이 있다.

•••• Rate Monotonic (RM)Rate Monotonic (RM)Rate Monotonic (RM)Rate Monotonic (RM)

Rate Monotonic 방식은 각각의 태스크중 생성 주기가 가장 짧은 태스크가

가장 높은 우선 순위를 가지는 스케줄링 방식이다. [그림 2-1]은 RM 스케줄

링 방식에 대하여 설명 한 것으로 그림의 세 개의 태스크는 모두 일정한 간격

으로 생성되고 있다. 그리고 가장 빠른 생성 주기를 가지고 있는 태스크 1은

스케줄링 알고리즘에 따라 선점의 최 우선권을 가지며 태스크 2와 태스크 3은

그 뒤를 따르고 있다. [그림 2-1]의 마지막 라인은 이 세 개의 태스크들이 서

로 선점되는 과정을 보여주며 violation of deadline 지점에서 태스크 3의 수

행 시간이 데드라인을 넘어가는 것을 알 수 있다.

[그림 2-1] RM으로 스케줄링한 예

10

•••• Deadline Monotonic (DM) Deadline Monotonic (DM) Deadline Monotonic (DM) Deadline Monotonic (DM)

Deadline Monotonic 스케줄링은 말 그대로 데드라인이 가장 짧은 태스크에게

가장 높은 우선 순위를 준다. [그림 2-3]을 보면 태스크 2가 가장 짧은 데드

라인을 가지고 있다는 것을 알 수 있다. 그리고 정적 스케줄링 방식이기 때문

에 태스크의 종료까지 이 순위는 변하지 않는다. 따라서 태스크 2는 다른 태

스크보다 우선 해서 실행된다.

[그림 2-3] DM으로 스케줄링한 예

2.3.3 동적 우선순위 스케줄링

동적 우선순위(Dynamic Priority)는 수행 중에 언제든지 태스크의 우선순위

를 바꾸는 것이 가능한 경우를 말한다. 동적 우선순위 방식을 사용하는 스케

11

줄링에는 Earliest DeadLine First (EDF)와 Time Driven Scheduler (TDS),

Least Laxity First (LLF), Shortest Remaining Time (SRT)등이 있다.

•••• Earlist Deadline First (EDF)Earlist Deadline First (EDF)Earlist Deadline First (EDF)Earlist Deadline First (EDF)

DM(Deadline monotonic) 스케줄링 방식과 마찬가지로 가장 짧은 데드라인

을 가지고 있는 태스크에 가장 높은 우선 순위를 준다. 그러나 동적으로 할당

되기 때문에 이 우선 순위는 시간의 경과에 따라 바뀔 수 있다. [그림 2-4]에

서 보면 처음에는 가장 짧은 데드라인을 가지고 있는 태스크 2가 가장 높은

우선 순위를 가지고 선점이 되는 것을 볼 수 있으나 태스크 3의 데드라인에

가까워 질 수록 태스크 3에게 우선권을 뺏기고 있는 것을 알 수 있다. 따라서

모든 태스크의 실시간 요구를 만족시키는 데 적합한 스케줄링 방식이라는 것

을 알 수 있다. [그림 2-4]에서도 지금까지와는 다르게 태스크 3의 데드라인

역시 지켜짐을 볼 수 있다.

[그림 2-4] EDF로 스케줄링한 예

12

제제제제 3333 장장장장 BrickOS BrickOS BrickOS BrickOS 스케스케스케스케줄줄줄줄링링링링의의의의 문제점과문제점과문제점과문제점과 개선방안개선방안개선방안개선방안

3333.1 .1 .1 .1 BrickOSBrickOSBrickOSBrickOS의의의의 스케스케스케스케줄줄줄줄링링링링 기법기법기법기법

brickOS는 표면적으로 실시간 오퍼레이팅 시스템임을 표방한다. 그 이유로

brickOS가 라운드 로빈 스케줄링 방식과 우선순위 기반의 선점형 스케줄링

방식을 혼합하여 사용한다는 것을 들 수 있다.

3.1.1 라운드 로빈 스케줄링 기법

라운드 로빈 스케줄링은 각 태스크에게 CPU 실행 시간을 골고루 나눠준다.

각 태스크는 라운드 로빈이라는 이름이 뜻하는 것처럼 지정된 시분할

시간만큼 번갈아가면서 수행된다[9]. 런타임 카운터는 클럭 틱(clock tick)마다

각 태스크의 남아 있는 수행시간을 점검한다. 태스크가 지정된 시분할을 모두

소모하면 카운터를 지운 뒤 태스크를 라운드 로빈 사이클의 마지막에 둔다.

새로 추가된 같은 우선 순위의 태스크 역시 라운드 로빈 사이클의 마지막에

놓여진다. 이 때 태스크의 런타임 카운터는 0으로 초기화 된다. 아래의

[그림3-1]은 라운드 로빈 스케줄링 방식을 그림으로 표현하였다.

[그림 3-1] 라운드 로빈 스케줄링 기법

13

BrickOSBrickOSBrickOSBrickOS에서의에서의에서의에서의 라운드라운드라운드라운드 로빈로빈로빈로빈 스케쥴링스케쥴링스케쥴링스케쥴링

[그림 3-2]는 task_switch_handler함수의 일부분으로 라운드 로빈

스케줄링에 직접적인 영향을 미치는 부분이다.

[그림 3-2] task_switch_handler 함수

task_switch_handler 함수는 타이머 인터럽트가 발생할 때마다 호출되는

함수이다. RCX에서 타이머 인터럽트는 매 1ms마다 발생하기 때문에 빠른

수행을 위해 어셈블리어로 작성되었으며 매 수행 시 마다 각각의 외부

장치들의 핸들러를 호출하여 동작 여부를 결정한다. 이러한 것으로 미루어

볼때 BrickOS는 외부 장치와의 통신 수단으로 인터럽트 방식 대신 폴링

14

방식을 사용한다는 것을 알 수 있다. [그림 3-2]는 그 중 라운드 로빈

스케줄링을 하는 부분으로 매 호출 시마다 tm_current_slice값을 감소 시킨후

0이 되었을 때 tm_switcher_vector가 가리키는 곳으로 jump하는 것을 볼 수

있다. tm_switcher_vector에는 현재 동작하고 있는 스케줄러의 주소가 담겨

있으므로 즉 일정한 시간이 지나면 스케줄러를 호출시킨다. 현재 brickOS의

default tick값은 20으로 되어 있기 때문에 매 20msec마다 스케줄러의 호출이

일어난다.

3.1.2 우선 순위 기반의 선점형 스케쥴링

[그림 3-3]과 같이 우선순위 기반의 선점형 스케줄링 알고리즘을 사용할

경우, 임의의 시점에 수행중인 태스크는 항상 시스템에서 실행 가능 상태에

있는 태스크 중 우선 순위가 가장 높은 태스크이다[9,10]. 우선 순위 기반의

선점형 스케줄러는 각 태스크별로 우선 순위를 매긴 후 가장 높은 우선

순위를 가진 태스크를 수행 시킨다. 현재 실행 중인 태스크보다 우선 순위가

높은 태스크가 실행 가능 상태가 되면 커널은 즉시 현재 태스크의 문맥을

TCB에 저장하고 우선 순위가 더 높은 태스크로 실행권을 넘긴다.

[그림 3-3] 우선순위 기반의 선점형 스케줄링

15

BrickOSBrickOSBrickOSBrickOS에서의에서의에서의에서의 우선순위우선순위우선순위우선순위 기반의기반의기반의기반의 선점형선점형선점형선점형 스케줄링스케줄링스케줄링스케줄링

BrickOS에서는 [그림 3-4]에서 보듯이 3가지의 서로 다른 우선순위를 제공

하고 있다.

[그림 3-4] brickOS에서 제공하는 우선 순위

그리고 각 태스크의 상태를 아래와 같이 4가지[10]로 분리해 놓고 있다.

● task Running

task가 실행되고 있는 상태를 의미한다. 해당 태스크는 Round Robin

스케줄링이 아닌 이상 언제든지 자신보다 우선순위가 높은 태스크가 없다면

수행될 수 있다. 라운드 로빈 스케줄링에서는 차례대로 수행된다.

● task Wating

해당 태스크가 어떠한 이벤트를 기다리면서 대기하는 상태이다. 이러한

이벤트에는 signal, irq, io request, semaphore 자원 등이 있을 수 있다.

● task Sleeping

해당 태스크는 IDLE 상태이나 언제든지 실행할 준비가 되어 있다.

● task Zombie

해당 태스크는 수행이 종료 되어 있는 상태이다. 그러나 메모리 스택이 아직

반환되지 않았기 때문에 태스크 정보가 메모리에 남아있다.

16

BrickOS는 [그림 3-4]의 우선 순위 정보와 해당 태스크들의 상태에 대한

정보를 바탕으로 선점이 가능한 스케줄링 서비스를 제공해 주고 있다 [그림

3-5]는 brickOS의 스케줄링 알고리즘을 보여준다.

[그림 3-5] brickOS의 스케줄링 알고리즘

17

스케줄러가 호출 될때 현재 수행중인 태스크의 스택 포인터(old_sp)를 인자

로 가지고 온다[5]. 이는 태스크의 스택에 실제 태스크의 수행 코드의 시작

위치가 저장되어 있기 때문이다. [그림 3-6]을 보면 태스크의 종료 위치와 시

작 위치가 태스크 스택의 맨 상단에 위치 해 있음을 알 수 있다. 스케줄러 실

행 중 현재 태스크를 수행시킬 필요가 있을 때 인자로 가져 온 스택 포인터를

활용한다.

&rom_ocia_return

Address of interrupted task’s nextinstructionROM callee saved data

&systime_tm_returnsaved context of current task,R1...R5

[그림 3-6] SLEEPING 태스크의 스택 구조

BrickOS는 우선순위기반의 선점형 서비스를 지향하고 있기 때문에 스케줄링

시 가장 높은 우선 순위를 찾아야 한다. BrickOS는 이를 위해 두개의 리스트

를 이용하여 스케줄링을 하고 있다. 그림 [3-7]을 보면 각각의 우선 순위 노

드에 태스크 노드들이 달려 있는 것을 볼 수 있다. 그리고 가장 높은 우선 순

위 노드는 항상 P_HEAD로 지정되어 있다. 스케줄러가 호출 되면 가장 먼저

P_HEAD 를 찾는다. 이는 다음 수행할 태스크를 찾을 때 항상 가장 높은 우

선 순위를 가지는 노드에서부터 시작한다는 것을 의미한다. 또한 그 우선순위

노드의 태스크들이 모두 종료 되지 않으면 다음 우선 순위의 태스크는 실행

될 수 없다. 예를 들어 그림 [3-7]에서 가장 높은 우선 순위인 20에 달려 있

18

는 3개의 태스크들의 상태가 모두 task_Waiting 이거나 task_Jombie가 아니

면 다음 우선 순위인 10과 1의 태스크들은 실행 되지 않는다. 더불어 매

20mec마다 스케줄러의 호출이 일어나는 라운드 로빈 방식이기 때문에 새로운

상위 우선 순위의 태스크가 생성 되면 스케줄러 호출시 태스크 스위칭, 즉 태

스크 선점이 일어나게 된다. 이를 종합해 볼 때 BrickOS는 우선 순위 기반의

선점형 서비스를 지원한다. [그림 3-8]은 이를 그림으로 나타내고 있다.

[그림 3-7] 우선 순위 리스트와 태스크 리스트의 관계

[그림 3-8] 선점형 스케줄링과 라운드 로빈 스케줄링의 사용

19

3.23.23.23.2 기존기존기존기존 스케줄링의스케줄링의스케줄링의스케줄링의 문제점문제점문제점문제점

3.2.1 태스크 생성부터 선점 사이의 지연

실시간 서비스가 필요한 태스크는 수행 중의 불필요한 시간의 지연을

최소화 해야 한다[11,12]. BrickOS는 태스크 간에 우선 순위에 의거하여

선점을 허용하지만 즉각적인 태스크의 교환을 지원하지는 않는다. 따라서

라운드 로빈 스케쥴링 방식을 사용하고 있는 BrickOS는 선점을 유도할 다음

스케쥴러의 호출까지 지연을 생성 시킬 수 있다. [그림 3-9]에서 보듯이

태스크1의 수행 중 실시간 태스크인 태스크2가 실행 큐에 들어왔을 때 실제

수행까지 지연이 생긴다. 즉 실시간 서비스를 원하는 태스크가 실행 큐에

들어 왔을 때 다음 스케쥴러 호출까지 최대 시분할 간격만큼의 불필요한

시간을 소모하게 된다.

[그림 3-9] 태스크 생성시 발생하는 지연 시간

20

3.2.2 불필요한 스케줄러의 호출에 따른 지연

BrickOS의 스케쥴러에서 발생시키는 또 다른 지연으로 스케줄러 호출 자체

를 들수 있다. 우선 순위 기반의 선점형 알고리즘은 해당 우선 순위 목록에

수행될 태스크가 존재하면 더 높은 우선 순위를 가지는 태스크가 우선 순위

리스트에 새로이 추가 되는 경우와 해당 우선 순위 리스트에 수행 중인 태스

크가 모두 제거되거나 WAITING상태에 빠지지 않는 한 하위 우선 순위 목록

에 있는 태스크를 수행 시키지 않는다[5]. 이는 만약 가장 높은 우선 순위 리

스트에 태스크가 하나만 존재하면 이 후 반복되는 스케줄러가 그 태스크가 종

료 할때까지 계속하여 현재 수행중인 태스크를 선택 한다는 말이 된다. 따라

서 하나의 실시간 태스크가 가장 최상위 우선 순위를 가질 경우에 스케줄러는

다른 태스크를 실행시키지 않는다. 결과적으로 최우선 순위를 가진 실시간 태

스크가 있을 때 스케줄러는 호출할 때마다 실시간 태스크를 선택 한다. 그러

므로 실시간 태스크가 수행 중에는 호출되는 스케쥴러의 필요성은 상실되게

된다. 따라서 불필요한 스케줄러의 호출을 제한할 경우 [그림 3-10]에서 보듯

이 전체 태스크 수행시간에서 태스크 교환에 따른 부가적인 동작 시간과 스케

줄러 자체의 수행 시간만큼을 줄일 수가 있다. [그림 3-11]의 윗 그림은 일반

적인 태스크 수행시 중간 중간 수행되는 스케줄러를 보여주고 있다. [그림 3-

11]의 아래 그림은 태스크 수행시 스케줄러의 호출을 제한한 모습이다. 그림

에서 보듯이 지속적인 태스크 수행 시 스케줄러의 호출을 제한하면 태스크 수

행 시간의 지속적인 감소효과를 낼 수가 있다. 그러나 이처럼 스케줄러의 호

출을 제한하면 여러가지 문제점을 야기 시키게 된다[13,14]. 따라서 이러한

문제점을 보완하면서 수행속도를 향상 시키는 방법이 필요하다. 이는 다음 장

에서 다루도록 한다

21

[그림 3-10] 스케쥴러 호출 시 소요 시간

[그림 3-11] 태스크 수행 시간 비교

22

3.3.3.3.3333 개선된개선된개선된개선된 실시간실시간실시간실시간 스케줄링스케줄링스케줄링스케줄링

3.3.1 개선된 실시간 스케줄링 알고리즘

전 장에서 언급한 문제점들은 일정한 타이머 틱을 두고 스케줄러를 호출하는

라운드 로빈 스케줄러이기에 발생되는 문제이다. 라운드 로빈 방식은 모든

프로세스에게 고른 CPU 시간을 주기 때문에 프로세스의 기아 현상을

해결하고 동시에 여러 일을 처리하기에는 효율적이나 일의 중요도에 따라

작업이 할당되야 하는 실시간 시스템에는 부적합하다. BrickOS는 이를

보완하기 위해 우선순위에 따른 선점형 서비스를 제공하였으나 3.2절에서

언급했던 것과 같이 몇가지 미흡한 점이 있다.

따라서 이를 해결하기 위해서는 라운드 로빈 방식을 포기 하여야 하나

실시간 태스크를 제외한 일반 태스크의 스케줄링을 위해서는 라운드 로빈

방식이 필요하다. 그러므로 기존의 스케줄러와 새로 설계될 실시간

스케줄러는 서로 공존하면서 필요에 따라 번갈아 호출 되어야 한다. 이는

이전에 연구가 되었던 이중 실시간 스케줄링 방식[12]과 기본적인 컨셉은

같지만 스케줄링 호출에 있어 BrickOS의 kernel에 맞게 변형이 되었다. [그림

3-12]는 새로 제안하는 알고리즘을 위해 커널상에서 수정 되어야 하는

타이머 인터럽트 핸들러와 새로운 실시간 스케줄러의 동작 과정을 보여주고

있다. 매 20sec마다 스케줄러를 호출하는 기존의 방식과는 달리 매 1ms마다

호출되는 타이머 인터럽트 핸들러에서 스케줄러의 호출 여부를 매번 판단한다.

이 때 호출 여부의 판단 시간을 최대한으로 줄이기 위해 단순히 플래그의

세팅 여부에 따라 이를 판단하도록 하였다. 새로운 실시간 태스크가 생성되면

다음 타임 틱까지 기다리지 않고 즉시 스케줄러를 호출 한다. [그림 3-

12]에서 보듯이 새로이 생성된 실시간 태스크가 있으면 기존의 스케줄러 호출

23

시스템을 정지 시킨다. 실시간 태스크가 수행중일때는 일반 태스크의 수행이

필요가 없기 때문이다. 그런 다음 실시간 스케줄러를 호출한 뒤 태스크가

종료 할 때까지 실시간 스케줄러를 호출 하지 않는다. 이를 통해 새로운

실시간 태스크가 생성시 생기는 지연과 불필요한 스케줄러의 호출에 의해

야기되는 지연을 줄일 수 있다.

[그림 3-12] 타이머 인터럽트 핸들러와 실시간 스케줄러의 동작 과정

개선된 실시간 스케줄링 알고리즘에는 실시간 태스크를 정지 시키고

스케줄링을 해야할 예외 상황이 있는데 [그림 3-12]에 나와 있듯이 크게

3가지로 나눌 수가 있다. 첫번째는 실시간 태스크의 수행중 또다른 실시간

태스크가 들어 왔을 때 두 실시간 태스크 간의 중요성 여부를 판단하기

위해서다. 그러나 이 논문에서는 실시간 태스크 수행 중 발생하는 지연

시간을 줄이는 것에 중점을 두고 있으며 실시간 태스크 간에 우선 순위에는

차이를 주지 않기 때문에 실시간 태스크 간의 스케줄링은 고려하지 않았다.

따라서 새로운 실시간 태스크는 단순히 실시간 태스크의 실행 큐에 가장 뒤에

위치 하도록 하였다. 두번째 예외 사항은 실시간 태스크를 생성하는 데

24

필요한 일반 태스크의 수행이 요구될 때이다. 현재 BrickOS에서는 실시간

태스크 수행중 패킷 송수신 작업은 불가능 하다. 그러나 어떤 실시간

서비스를 요구하는 패킷이 전송 되었거나 전송될 필요가 있을 때 이를 처리해

주는 작업이 필요하다. 마지막은 실시간 태스크가 어떠한 이벤트를 기다리고

있을 상황이다. 이때는 이벤트의 발생까지 자원의 효율성을 위해 일반

태스크를 실행하는 것이 바람직하다. 따라서 이벤트가 일어나기 전까지

기존의 스케줄링 방식으로 복귀한다. [그림 3-13]은 이러한 모든 상황을

고려한 최종 스케줄링 알고리즘을 순서도로 보여준다.

[그림 3-13] 개선된 실시간 스케줄링 알고리즘에 대한 순서도

25

3.3.2 개선된 실시간 스케줄러의 구현

위에서 제시한 알고리즘을 구현하기 위해서는 크게 타이머 인터럽트 핸들러

와 태스크 생성 함수의 수정 그리고 실시간 스케줄러 함수가 필요하다.

타이머타이머타이머타이머 인터럽트인터럽트인터럽트인터럽트 핸들러핸들러핸들러핸들러

[그림 3-14]는 수정된 타이머 인터럽트 핸들러의 코드의 일부로서 타이머

인터럽트가 발생할 때 스케줄러의 호출을 담당하는 부분이다. 실시간 태스크

의 생성여부와 현재 수행중인 실시간 태스크의 존재 여부를 알기 위해

f_new_rtask, f_run_rtask 두 개의 플래그가 사용되었다. 새로운 실시간 태스

크가 생성되면 크리티컬 섹션을 체크한 뒤 실시간 스케줄러를 호출한다. 만약

새로운 실시간 태스크가 생성되지 않았지만 현재 수행중인 실시간 태스크가

존재하면 스케줄러를 호출하지 않는다. 만약 위의 조건에 모두 만족되지 않으

면 기존의 스케줄링 알고리즘에 따라 태스크의 동작 여부가 결정된다. [그림

3-14]의 코드에 대한 설명은 다음과 같다.

A : 새로운 실시간 태스크의 생성 여부를 판별, 만약 새로이 생성된 실시간 태

스크가 있으면 실시간 스케줄러의 호출을 위해 크리티컬 섹션을 체크한다. 크

리티컬 섹션 체크에 실패하면 다음 인터럽트 발생때 다시 시도 한다. 크리티

컬 섹션 체크에 성공하면 실시간 스케줄러의 호출을 위해 rt_switch로 분기한

다.

B : rt_switcher_vector값으로 분기, 즉 실시간 스케줄러 함수로 분기한다.

C : 현재 수행중인 실시간 태스크가 있는지를 확인한다. 있을 경우 스케줄러의

호출을 제한한다.

D : 기존의 스케줄링 알고리즘에 따라 동작한다.

26

[그림 3-14] 수정된 타이머 인터럽트 핸들러 함수

27

수정된수정된수정된수정된 태스크태스크태스크태스크 생성생성생성생성 함수함수함수함수 ( ( ( ( new_new_new_new_execi() )execi() )execi() )execi() )

기존의 BrickOS에서 execi()함수는 메모리 할당과 태스크 구조체 생성등 태

스크 생성에 필요한 일반적인 작업을 한 뒤 새로 생성한 태스크를 할당 받은

우선순위에 따라 실행 리스트(RUN QUEUE)에 삽입해 주는 작업을 했다. 수정

된 생성 함수는 실행 리스트에 삽입 하기 전까지는 전과 동일한 작업을 한다.

그러나 기존에 있는 실행 리스트와는 별도로 있는 실시간 실행 리스트에 새로

생성된 태스크를 삽입한뒤 f_new_rtask를 세팅하여 타이머 인터럽트 핸들러에

이를 알린다. 만일 실행 리스트에 다른 실시간 태스크가 존재하면 새로운 태

스크는 기존의 태스크 리스트의 가장 뒤에 붙는다. [그림 3-15]는

new_execi()의 코드중 이에 관련된 부분을 보여 준다.

[그림 3-15] 수정된 execi() 함수

28

실시간실시간실시간실시간 스케줄러스케줄러스케줄러스케줄러 함수함수함수함수 ( ( ( (realtimerealtimerealtimerealtime_tm_scheduler)_tm_scheduler)_tm_scheduler)_tm_scheduler)

현재 실행 중인 실시간 태스크의 상태를 확인한 후 다음 실행할 태스크를

찾는 역할을 한다. 실시간 태스크의 스케줄링만을 관할하기 때문에 실시간 태

스크가 없을 시에는 호출 되지 않는다. 실시간 태스크 간의 우선순위를 두지

않았기 때문에 단순히 다음 실시간 태스크로의 전환만이 주된 임무이다. 전환

이 일어나는 상황은 새로운 실시간 태스크의 생성에 관련한 일반 태스크의 작

업이 필요할 때와 현재 수행중이 실시간 태스크가 새로운 이벤트를 위해 대기

하고 있을 때이다. 실시간 태스크간에도 우선순위를 두어 작업의 경중을 조절

할 수 있지만 본 논문에서 지향하는 지연시간 감소와 큰 관련이 없기 때문에

차후에 구현하도록 한다. [그림 3-16]은 실시간 스케줄러 함수의 코드중 중요

부분을 보여 준다.

[그림 3-16] 실시간 스케줄러 함수

29

제제제제 4444 장장장장 실험실험실험실험 및및및및 결과결과결과결과

4장에서는 본 논문에서 구현한 실시간 시스템을 대상으로, 실시간 태스크를

생성하고 이를 처리하는 과정에 대한 실험 및 결과를 보여준다. 또한 기존의

스케줄링 방식과 비교하여 본 논문에서 제안한 실시간 스케줄링 방식의

성능을 평가한다.

4444.1 .1 .1 .1 실험실험실험실험 환경환경환경환경

본 논문에서 제안한 실시간 시스템은 리눅스 커널 2.6.8버전의 데비안

리눅스 시스템에서 h8300-hitachi-hms-gcc 2.95.2 버전의 크로스

컴파일러를 이용하여 구현하였다. host 컴퓨터의 시스템 사양은 Pentium III

800MHz의 PC를 사용하였고, firmdl3와 dll 프로그램을 업로드용으로

사용하였다.

실험 데이터를 판별하기 위해 RCX의 외부 출력 장치중 하나인 lcd를 고려

하였으나 표현가능한 숫자가 4자리를 넘지 못하기 때문에 정상적인 결과

데이터 출력이 불가능하였다. 이에 호스트 컴퓨터와의 통신을 통해 결과

데이터를 host 컴퓨터에서 확인하는 방법을 채택하였다. 이를 위해 lnphost

프로그램을 사용 하였으며 lnphost[15]는 host 컴퓨터가 받은 패킷중 lnp

프로토콜을 사용하는 모든 데이터를 화면에 출력하는 프로그램이다.

본 논문에서 제한하는 실시간 시스템의 성능 향상 정도를 측정하기 위해

태스크의 수행 속도를 측정하여야 했다. 그리고 이를 위해 시스템에서

제공하는 get_system_up_time 함수를 사용하였다. get_system_up_time

함수는 현재의 시스템 타임값인 sys_time값을 반환하는 함수이다.

30

4.2 4.2 4.2 4.2 실험실험실험실험 및및및및 결과결과결과결과

실험은 총 3가지로 분류하여 시행되었다. 첫번째는 단일 실시간 태스크의

생성부터 시행까지의 과정 중 발생하는 지연을 줄이는 알고리즘의 성능을

평가하기 위한 실험이며, 두번째는 실시간 태스크 수행시 불필요한

스케줄러의 호출을 막아 태스크 수행 속도의 향상을 도모하는 알고리즘을

평가하는 실험이다. 3번째 실험은 위의 두가지 알고리즘을 모두 적용 시켰을

시 즉, 본 논문에서 제안한 실시간 시스템을 사용 했을 시 단일 실시간

태스크의 수행 속도 향상 정도를 측정 하였다.

모든 실험은 하나의 단일 실시간 태스크를 사용하였다. 이 단일 실시간

태스크는 하나의 LOOP만을 가지고 있는 더미 태스크다. 그리고 각각의

실험은 LOOP의 횟수를 변경하면서 수행된다. 이는 실시간 태스크의 작업량에

따른 수행 시간의 변화를 보기 위해서이다. 그외에 수행중인 태스크는

BrickOS가 서비스 하는 3개의 일반 태스크가 있다. 이 태스크들은 가장 높은

우선순위를 가지고 실행중이며 모두 외부 장치의 이벤트를 기다리고 있다. 본

실험에서는 실시간 태스크의 실행중 야기되는 지연을 해소함으로서 얻을수

있는 시간의 이익을 아는 것이 목적이기 때문에 일반 태스크의 이벤트가

일어나지 않도록 하였다. 따라서 실험 태스크는 필요한 자원이나 이벤트를

요구하지 않으며 태스크 수행중 이벤트 상태에 빠지지 않도록 하였다.

모든 실험에서의 데이터 값은 태스크의 생성에서부터 종료까지 걸린 총

시간이며 그 사이에 수행 속도에 영향을 줄수 있는 타이머 인터럽트를 제외한

외부 인터럽트를 발생시키지 않았다. 또한 새로운 일반 태스크의 생성 및

종료와 같은 이벤트 역시 수행 되지 않으며 외부와의 통신 역시 실험

태스크의 수행 중이 아닐 때만 가능하다.

31

[표 4-1]은 실시간 태스크 생성부터 수행까지의 지연을 없애는 알고리즘을

적용한 후 실험한 결과이다. 결과에서 보듯이 개선된 스케줄링을 사용할 경우

태스크 수행 시간의 감소를 보이고 있다. 그렇지만 전체 태스크 속도에 있어

크게 영향을 미치는 수준은 아니며 태스크의 작업량에 따라 감소되는 양의

변화는 미미하기 때문에 작업량이 많아 질수록 줄어드는 시간의 비율은 점점

감소 한다.

[표 4-1] 태스크 생성시 발생하는 지연 감소

loop 횟수 기존 스케줄링 개선된 스케줄링 수행시간의 차이

10000 9560 ms 9394 ms -166 ms (1.73%)

20000 14720 ms 14552 ms -168 ms (1.14%)

30000 19243 ms 19077 ms -166 ms (0.86%)

40000 23874 ms 23706 ms -168 ms (0.70%)

50000 28359 ms 28190 ms -169 ms (0.59%)

두번째 실험은 실시간 태스크의 수행시 불필요한 스케줄러의 호출을

제한하는 알고리즘을 적용하였다. [표 4-2]에서 보듯이 이 알고리즘을

적용하면 전체 실시간 태스크의 수행 시간이 감소한다는 것을 알 수 있다.

32

게다가 기존 스케줄링 방식에서의 태스크 수행 시간과 개선된 스케줄링

방식에서의 태스크 수행 시간의 차이는 선형적으로 증가한다. 이는 태스크의

작업량이 많아 지는 것에 비례하여 줄어 드는 시간 역시 증가 한다는 것을

의미한다. 따라서 일정한 비율만큼의 수행 시간 감소 효과를 낼 수 있다.

[표 4-2] 스케줄러 호출 제한에 따른 태스크 수행 시간의 변화

loop 횟수 기존 스케줄링 개선된 스케줄링 수행시간의 차이

10000 9570 ms 8796 ms -774 ms (8.09%)

20000 14350 ms 13426 ms -924 ms (6.43%)

30000 19128 ms 17882 ms -1246 ms (6.52%)

40000 23898 ms 22475 ms -1423 ms (5.95%)

50000 28378 ms 26563 ms -1815 ms (6.39%)

이번 실험에서는 위의 두 알고리즘을 복합하여 구현한 실시간 시스템에서

태스크의 수행 시간을 측정하였다. 측정 결과 기존 스케줄링 방식을 사용했을

때 보다 개선된 실시간 스케줄링 알고리즘을 적용 했을 시 확실한 수행

시간의 감소가 나타남을 알 수 있었다. 감소의 폭 또한 위의 두 알고리즘을

적용 했을 때보다 컸으며 차이 또한 지속적으로 증가하였다. 이를 통해 본

논문에서 제안한 시스템에서의 실시간 태스크 수행이 기존의 시스템에서보다

빠르게 완료 됨을 확인 할 수 있었다. [표 4-3]은 실험 결과를 표로, [그림

33

4-1]은 결과 값을 그래프로 나타내고 있다.

[표 4-3] 기존 시스템 과 실시간 시스템 사이의 태스크 수행 시간 비교

loop 횟수 기존 시스템 실시간 시스템 수행시간의 차이

10000 9551 ms 8793 ms -758 ms (7.93%)

20000 14343 ms 13183 ms -1160 ms (8.08%)

30000 19234 ms 17641 ms -1593 ms (8.28%)

40000 23890 ms 21955 ms -1935 ms (8.09%)

50000 28382 ms 26167 ms -2215 ms (7.80%)

작업량이 늘어나도 일정한 비율을 유지하며 수행 시간의 감소가 일어남을 알

수 있다. 이는 작업량이 증가 하면 지연 시간의 감소 역시 늘어 난다는 것을

의미한다. 밑의 그래프는 이러한 선형적인 차이를 그래프로 보여준다.

0

500

1000

1500

2000

2500

10000 20000 30000 40000 50000

loop 횟수

수행시간의 차이

[그림 4-1] 기존 시스템과 실시간 시스템 간의 태스크 수행 시간 차이

34

제제제제 5 5 5 5 장장장장 결론결론결론결론

BrickOS는 기존의 RCX 펌웨어를 능가하는 임베디드 오퍼레이팅 시스템이다.

이 오퍼레이팅 시스템은 기존 펌웨어보다 보다 더 많은 서비스를 RCX에

제공하기 위해 다양한 기능을 구현 하였다. 우선 순위 기반의 선점형

스케줄링 방식은 그 중에 하나로써 BrickOS는 이 스케줄링 방식을 통해

실시간 서비스의 지원을 도모 하였다. 그러나 실제 실시간 서비스를

제공하기에는 몇 가지 문제점이 있다. 실제 BrickOS는 실시간 태스크의

수행을 위한 어떠한 자료 구조도 지원 하고 있지 않다. 뿐만 아니라 실시간

서비스인 점을 고려해서 기존의 스케줄링 방식은 몇 가지의 지연 시간을

가지고 있기 때문에 Best Effort Service를 지원해야 하는 실시간 오퍼레이팅

시스템에서 이러한 스케줄링 방식은 적합하지 않다.

이에 본 논문에서는 BrickOS가 실시간 태스크를 처리 할 수 있도록 기본

자료 구조를 추가 하였다. 그리고 기존 시스템에서 실시간 태스크를 처리 할

때 일어나는 지연 시간을 보완 할 수 있는 새로운 실시간 스케줄링

알고리즘을 제안하였다. 또한 제안한 알고리즘을 실제로 구현하기 위해

BrickOS의 커널을 분석 하였으며, 커널 중 태스크의 생성과 스케줄링에

관련된 부분들을 수정, 추가 하였다. 그리고 제안 된 알고리즘의 성능 향상을

평가하기 위한 실험은 본 논문에서 제안한 알고리즘에서의 실시간 태스크

수행이 기존의 스케줄링 방식보다 약 8%정도 빠르게 진행 되었다는 것을

보여 주었다. 이는 제안한 실시간 시스템이 지연 시간의 감소를 통해 기존의

시스템보다 향상된 best effort service를 해 준다는 것을 의미하며 더불어

보다 향상된 실시간 성을 가지고 있다는 것을 말한다.

하지만 본 논문에서 제안한 실시간 태스크에는 보완해야 할 점이 있다. 서로

35

다른 실시간 태스크간에 스케줄링 알고리즘이 정의 되어 있지 않다는 점이다.

단일의 실시간 태스크만이 동작할 때는 문제가 없지만 동시에 여러개의

실시간 태스크가 작업을 요구 할 때는 단순히 FIFO의 법칙에 의해 태스크가

동작하므로 나중에 들어온 태스크의 실시간 성을 지켜주는 데 문제가 생길 수

있다. 이를 위해서는 향후에 따로 분리된 실시간 스케줄러에 EDF 나 LLF

방식을 적용하여 서로 다른 실시간 태스크들 간의 스케줄링도 고려해야

주어야 한다.

36

참 고 문 헌

[1] Ole Caprani, "RCX Manual", http://legolab.daimi.au.dk/CSaEA/RCX/

Manual.dir/RCXManual.html, Last updated 6.2.06.

[2] Kekoa Proudfoot, “RCX Internals”, stanford CA-LAB”, http://

graphics.stanford.edu/~kekoa/rcx, 1998,1999 stig.

[3] Stephen M Moraco, “Installing legOS on Debian GNU/Linux Systems”,

http://brickos.sourceforge.net/doc/install-Debian.html, 8 October, 2002.

[4] 이호익, 이대성, 김기창, “legOS(LEGO Operating Systme)의 커널 분석

및 수정을 통한 RCX간의 Routing 구현”, 제29회 한국정보과학회 추계학술

발표회 논문집(I), pp. 424-247, 2002.

[5] stig Nielsson, “Introduction to the legOS kernel”, http://legos.

sourceforge.net/docs/kerneldoc.ps, September 27, 2000.

[6] 김성민, 김윤수, 신동준, 송재각, 김주용, 고건 “FreeBSD 상에서의

실시간 스케줄러의 설계 및 구현”, 한국정보과학회 학술발표논문집 Vol.21,

No.2, 1994.

[7] William Wong, Embedded/systems/Software Editor, “BASICS of Design

REAL-TIME OPERATING SYSTEMS”, A Supplement to Element to

Electronic Design, September 1.

[8] 최영호, 백창우, 조경민, “Real Time OS for Ubiquitous Computing”,

10.21.2004.

37

[9] Qung Li Caroline Yao, “RTOS를 이용한 실시간 임베디드 시스템 디자인”,

CMPBOOKS, 2004, 2, 6.

[10] 김남윤, 신혁식, 김일석, 김연철, “내장형 시스템을 위한 실시간 커널의

설계 및 구현”, 한국정보과학회 가을 학술발표논문집 Vol, 20, No. 2, 1993

[11] 한대만, 최만억, 구용완, “주기 태스크의 종료시간을 보장하기 위한

확장된 혼합 실시간 스케줄링 알고리즘”, 한국정보과학회 가을

학술발표논문집 Vol.26.No.2, 1999.

[12] 인치호, “실시간 제약 커널 환경하에서의 이중 실시간 스케줄링 설계”,

전력전자학회논문지 제6권 제4호 2001.8.Toby Miller, "Detecting Loadable

Kernel Modules", http://www.s0ftpj. org/docs/lkm.htm, 2001.

[13] 최정훈, 김경화, 김두상, "실시간 리눅스에서 선택 알고리즘을 이용한

스케줄링 성능평가”, 한국정보과학회 가을 학술발표논문집 Vol. 29. No. 2,

2002.

[14] Andreas Gerstlauer, Haobo Yu, Daniel D.Gajski, “RTOS Modeling for

System Level Design”, Proceedings of the Design, Automation and Test in

Europe Conference and Exhibition, IEEE, 2003

[15] Stephan Hohrmann, sourceforge.net, “Lnphost project”, http://

lnphost.sourceforge.net, 2006.

제 1 장 서 론제 2 장 관련 연구2.1 MindStorm 및 RCX의 소개2.2 BrickOS kernel2.2.1 Kernel의 시작2.2.2 kernel의 동작구조2.2.2 메모리 관리2.2.3 Networking

2.3 실시간 스케줄링2.3.1 실시간 스케줄링 알고리즘의 개념2.3.2 정적 우선순위 스케줄링2.3.3 동적 우선순위 스케줄링

제 3 장 BrickOS 스케줄링의 문제점과 개선방안3.1 BrickOS의 스케줄링 기법3.1.1 라운드 로빈 스케줄링 기법3.1.2 우선 순위 기반의 선점형 스케쥴링

3.2 기존 스케줄링의 문제점3.2.1 태스크 생성부터 선점 사이의 지연3.2.2 불필요한 스케줄러의 호출에 따른 지연

3.3 개선된 실시간 스케줄링3.3.1 개선된 실시간 스케줄링 알고리즘3.3.2 개선된 실시간 스케줄러의 구현

제 4 장 실험 및 결과4.1 실험 환경4.2 실험 및 결과

제 5 장 결론