Real Time Operating System 이라고 불리는 운영체제들이 Embedded System 에 일반적으로 사용된다. 이 들 운영체제들의 특징이라고 한다면 General Purpose OS, 예를 들어 Windows, Linux, BSD 등에 비해서 커널이 작고 간단한 메모리 아키텍처를 사용한다는 것이 아닐까 한다.
물론 메모리 아키텍처와 RTOS 하고 직접적인 관련이 있는 것은 아니지만 Virtual Memory Address 를 사용하는 경우의 Context Switching 에 필요한 오버헤드나 Kernel 과 User Space 간의 메모리 분리에 따른 복잡도의 증가를 생각해 보면 소위 Real Time 이라는 이름을 걸고 OS Service 를 정의하는데 간단한 메모리 아키텍처를 택하는 것은 이해할 만 하다.
Embedded Linux 개발에 많이 사용되는 소위 Real Time patch 가 적용된 Linux distribution은 여전히 MMU 를 요구하고 Virtual Address scheme을 따른다. - 그래서 그런지는 몰라도 명확하게 RTOS로 분류하지는 않는 듯 하다 - 이러한 Virtual Address scheme 의 문제중의 하나는 메모리 할당이 동적으로 이루어 지다 보니 Performance 측면에 대한 간결한 예측이 불가능 하다는 데에 있다. 4GB Virtual Address 가 할당은 되지만 실제 잡히는 것은 아니고 코드나 데이터나 실제 필요한 시점에 할당되고 메모리가 부족하면 Swapping 이 발생한다... 이는 꼭 하드디스크를 사용하는 경우에만 해당하는 것이 아니고 Read-Only 파일시스템에서도 Code 영역에 대해서는 동적으로 발생하는 것으로 보인다.
이러한 불확실성은 타이밍이 매우 중요한 Real Time 데이터 처리에 많은 Risk를 남긴다. 동영상 플레이와 같이 많은 데이터가 일정 시간이내에 프로세스 되어 H/W 로 결과가 넘어가야 하는데 도중에 무슨 이유가 되었건 Swapping 이 발생할 경우 안정적인 화면처리에 문제가 발생할 수 있다.. 이러한 문제는 눈깜짝할 새에 복구가 될 수도 있지만 데이터의 이용방식에 따라서는 발생한 시점부터 계속 누적 영향을 미칠 수가 있다..
그렇다고 Virtual Address scheme을 사용하면서 동적 할당을 하지 않고 사용할 수는 없다. 방법이 없지는 않겠지만 벼룩 잡으려다 초가삼간 태우는 꼴이 나지 않을 가 하는 우려가 앞선다.
프로세싱 파워가 애플리케이션이 요구하는 수준보다 많이 높지 않는 Consumer Market 상품이라면 이러한 불확실성에 대한 Risk 분석은 반드시 필요하다. 고급의 Abstraction이 공짜일 수는 없다. 개발환경이 개선되는 부분도 있지만 Performance를 최적화해야 하는 기능에 대해서는 접근방법등에 제한이 있다는 한계를 분명히 인식해야 하지 않을까 한다.
