64비트 시스템으로 본「OS 패러다임의 변화」

64비트 시스템으로 본「OS 패러다임의 변화」

프로세서는 이미 64비트가 되었으나 운영체제는 32비트 골격을 유지하면서 64비트로 이행하고 있다. 64비트 운영체제가 조금 더 흔해지게 되면 데이터를 다루는 패러다임 자체에 변화가 올 것이고 사람들이 어떤 대상을 생각하는 방법이 바뀌기 시작하면 그때는 큰 변화가 올 것이다.

안윤호 (아마추어 커널해커)

2004/04/12

64비트 운영체제는 말 그대로 64비트 프로세서를 사용하기 위한 운영체제이다. 사용자들은 자신도 모르는 사이에 알파(alpha)나 울트라스팍(UltraSPARC)을 사용하는 서버에 접속하고 있고 이들이 바로 64비트 운영체제를 사용하고 있다. 이들 운영체제의 동작환경 중 어떤 부분이 32비트 모드이거나 32비트 호환 모드에 있다거나 컴파일러나 다른 중요한 애플리케이션이 32비트 모드에서 수행된다고 할지라도 사용자들은 이미 64비트의 프로세서와 그 힘을 이용하여 운영체제를 운영하고 있다고 봐야 한다. 그러나 독자들이 이 글에서 기대하는 것은 아마 64비트의 새롭고 거대한 능력과 데스크탑에 64비트가 사용되기를 기대하는 것일 터인데 아직은 조금 시기상조라고 말할 수 있다. 물론 최신의 맥이나 스팍을 데스크탑으로 사용한다거나 아니면 AMD의 해머가 있다. 그러나 아직은 64비트 운영체제는 시작 단계라고 봐야 한다. 현존하고 있는 64비트 운영체제 64비트의 프로세서는 이미 여러 종류가 있으며 이들을 사용하는 64비트 운영체제 역시 예전부터 존재했다. 비교적 용이하게 볼 수 있는 썬 마이크로시스템즈의 솔라리스 7 이후 울트라스팍을 사용하는 서버는 64비트 운영체제이지만 솔라리스 운영체제를 설명하는 서적(Solaris Internals, www.solarisinternals.com)에서도 크게 64비트에 대한 부분을 강조하고 있지는 않다. 이미 이전부터 많은 이행 노력이 있었기 때문일 것이다. 그러나 울트라 스팍에서 프로세서의 아키텍처는 크게 변했고 「UltraSPARC I/II User’s Manual」이나 「UltraSPARC III Cu User’s Manual」같은 썬의 문서들은 프로세서 아키텍처에 대해 설명하고 있다. IA-32보다 IA-64가 극단적으로 어려운 것과 마찬가지로 이들을 읽는 데는 상당한 인내심과 실력이 필요하다. MIPS의 R1000이나 파워PC 같은 아키텍처들도 이미 64비트로의 이행을 일치감치 끝냈다. 예전의 IA-32나 우아하고 간단했던 MIPS R2000, R3000 같은 아키텍처들처럼 간단하지가 않다. 현대의 전투기와 과거의 복엽기를 비교하는 것과 마찬가지라고 할 수 있다. 이미 많은 컴퓨터 회사들이 64비트를 지속적으로 써오고 있었음에도 불구하고 사람들이 64비트 시대로 접어들었다고 막연하게 실감하게 된 것은 인텔의 아이테니엄이 출시되고 난 후이다. 인텔과 마이크로소프트(이하 MS)가 대중들에게 어필하는 운영체제의 비즈니스 모델을 보이거나 새로운 대중적인 운영체제가 자리 잡게 된다면 그때는 의미 있는 운영체제로서 자리 잡을 것이다. 문제는 현재의 하이엔드 시장은 이미 64비트 CPU와 운영체제가 있으며 소비자들이 얼마나 64비트의 운영체제를 필요로 하는가에 대해서는 아직은 알 수 없다. 예측은 불가능하다 이 글은 64비트의 특별한 성질보다는 16비트를 거쳐 32비트에서 성숙한 운영체제들과의 연관성을 더욱 강조하게 될 것 같다. 또 이미 많은 기사들에서 EPIC이라던가 레지스터의 특이성, 성능 개선에 관련된 부분을 다루었기 때문에 독자들도 많이 알고 있는 내용일 것이다. 이전 글에서 언급했던 것처럼 시장의 예측은 언제나 불가능했다. 이른바 킬러 애플리케이션이라든가 새로운 수요가 나타나면 시장은 급변하는데 소비자들의 반응은 예측할 수 없으며 마케팅보다 더 중요하고 통제할 수 없는 변수이다. 32비트의 대성공 역시 인터넷과 웹의 폭발적인 성장과 멀티미디어 환경이 보편화되면서 가속화된 것이지만, 64비트를 성공적으로 정착시키는 요인이 무엇인지는 아직 잘 모르는 것이다. 일종의 킬러 애플리케이션이 게임이 될지 아니면 다른 멀티미디어 애플리케이션이 될지 예측은 불가능한 것이며, 따라서 회사들의 마케팅이 어떠하건 그 칼자루는 소비자에게 달려 있다. 다만 현재로서는 인텔과 MS가 소비자 시장에서 매우 중요한 공급자라는 것이 중요한 출발점이다. 이들은 몇몇 중요 벤더들과 협력해 아이테니엄이라는 프로세서를 가지고 시장을 향해 포문을 열었다. 여러 메이커들이 모두 선점하고자 혈안이 되어 있는 64비트 운영체제와 애플리케이션 시장은 일단 미션 크리티컬한 분야와 하이엔드 시장으로 높은 부가가치가 있다. 숙성이나 보급까지 얼마의 시간이 걸릴지는 알수 없지만 시장은 이제 진입단계로 들어갔다. 업체들의 시장 진입에 대한 열망은 다른 기사들을 통해서도 엿볼 수 있다. 2003년 4월 인텔의 보도자료 웹 사이트의 제목은 ‘IA 서버, 新 MS 운영체제로 세계 최고의 성능 기록 - 인텔, HP, MS 3사가 인텔　아이테니엄 2 프로세서 6M 기반 서버로 세계 No.1 TPC-C 벤치마크 결과 기록’으로 되어 있다. 아이테니엄 I에서는 조직적인 마케팅과 개발 협조가 부진했기 때문에 이해관계가 걸려 있는 업체들의 공동노력이 집중된 것이다. 이러한 노력의 목적은 새로운 시장을 창출해내기 위해서이다. 업체들은 시장의 진입시간을 앞당기고 싶은 것이다. 물론 그 이후에도 아이테니엄에 대한 기사와 벤치마크는 계속 보도자료에 나온다. 하지만 아직은 아이테니엄 서버를 도입하는 일이 보도자료에 나올 정도로 흔한 일이 아니다. 어떤 회사가 제온(Xeon) 프로세서를 서버를 도입했다고 뉴스에 나올 일은 아니다. 제온 프로세서는 흔하기 때문이다. 수세나 레드햇 같은 리눅스 업체들도 64비트에 대한 보도 자료를 내고 있다. 그러나 아직은 기술적인 자료가 많은 편은 아니다. 32비트의 흔적과 64비트로의 진화 8비트나 16비트에서 출발하여 32비트를 거쳐 64비트로 서서히 진화가 일어난 프로세서도 있고 알파와 같이 64비트에서 바로 출발한 프로세서도 있다. 그러나 64비트의 프로세서들은 과거의 칩들보다는 매우 복잡하며 다양한 특징을 갖게 되었다. 필자는 독자들이 「Great Microprocessors of the Past and Present (V 13.3.0)」를 한번 읽기를 권한다. 실제로 이 사이트는 여러 문헌에서도 참고자료로 언급하고 있으며 매우 좋은 내용을 담고 있다(www3.sk.sympatico. ca/jbayko/cpu.html). 이 글을 읽으면 64비트가 성능이 좋은 것은 사실이지만 특별한 것이 아니라는 사실을 알게 될 것이고 대부분의 아키텍처는 32비트로부터 진화한 것이고 64비트에 대한 신비감이 줄어든다면 좀 더 상식적으로 접근할 수 있을 것이다. 메모리 관리 부분의 변화 개인적인 생각이지만 64비트에 이르러 가장 큰 변화가 올 부분은 메모리 관리에 관한 부분일 것이다. 32비트 운영체제에 대해 64비트 운영체제가 갖는 가장 중요한 이점이라면 우선 메모리 대역폭과 메모리 공간의 증가 그리고 64비트 연산을 수행할 수 있다는 점일 것이다. 클럭의 속도나 수치 연산 프로세서의 성능이 32비트와는 비교가 되지 않지만 64비트 프로세서를 도입함으로서 바로 얻을 수 있는 최대의 효과는 64비트라는 데이터 폭이다. 데이터의 폭(width)이 64비트인 관계로 단순히 생각해도 32비트의 데이터 버스보다 같은 클럭에서 2배의 전송이 가능하다. 메모리의 데이터 대역폭은 CPU보다 메모리가 언제나 느리게 속도 증가가 일어난 관계로 프로세서의 성능증가에 있어 최대의 병목 지점이었다. 일반적으로 메모리와 CPU의 데이터 대역폭의 속도 불일치는 항상 몇 배 이상이었다. 간단히 말해서 CPU는 메모리가 데이터를 읽거나 쓰기를 마칠 때까지 어떠한 형태이건 대기 상태에 있어야 했다(메모리와 프로세서와의 관계에 대한 좋은 글들이 많지만 글을 쓰는 현재 필자의 머리 속에 떠오르는 것은 글은 Bruce Jacob의 「A case for studying DRAM issues at the system level」이다. B. Jacob의 글 중에는 읽을만한 내용이 많다). CPU에서 같은 데이터 전송속도가 하더라도 데이터의 전송대역폭(전송량)은 64비트에서는 2배가 되고 이것은 무시할 수 없는 수치이다. 종종 이러한 비교에는 4차선과 8차선 도로의 차량 통행량을 비교하곤 했다. 이것은 가장 간단한 비교이고 다른 요소가 더 있다. 예측 분기와 파이프라이닝을 넘어 메모리 접근의 최적화를 과감하게 시도했다. 대부분의 64비트 프로세서는 메모리 접근의 순서가 반드시 명령의 순서와는 일치하지 않지만 그 의존성은 보존된다는 것인데 프로세서의 메모리 접근마저도 내부에서 최적화되어 스케쥴되는 것이다. 가상 메모리 공간의 확장 그 다음으로는 가장 중요한 요소라고 할 수 있는 가상 메모리에 대한 부분이다. 마이크로 커널의 경우 가장 핵심적인 요소는 두 가지이다. 바로 메모리 자원의 관리와 스케쥴러이다. 자원의 관리는 내부적인 IPC(InterProcess Communication)에서 이 두 요소에 의해 이루어지는 것이다. 아무튼 이 두 가지만 있으면 마이크로 커널은 수행 가능하다. 다른 시스템 자원관리자들은 이 코어에 파일 시스템이나 통신 기타 IO 등을 덧붙이면서 만들어진다. 일반적인 모노리틱 커널마저도 이 두 가지 요소는 필수적이고 자원의 할당과 스케쥴링이 없으면 아무 일도 되지 않는다. 스케쥴링은 64비트라고 하여 쓰레드 연관을 제외하고는 특별한 이슈가 아니지만 너무 방대하여 이 글의 범위를 넘는 사항이다. 메모리 공간에서 가장 중요한 사실은 가상 메모리 공간의 구조이다. 우리가 알고 있는 일반적인 메모리 모델은 가상 메모리 상에서의 구조이다. 64비트에서 메모리 공간의 확장은 가상 메모리 공간의 확장을 말한다. 실제로 32비트 운영체제에서는 32비트 공간(2의 32승 그러니까 4GB) 정도의 메모리 공간이면 충분하다고 생각했으나 메모리 값이 떨어지자 4GB의 램을 갖는 기종들이 출현하게 되었다. 이러한 문제를 극복하기 위해 운영체제 내에서 여러 가지 편법이 동원되곤 했다. 어떤 프로세서는 이보다도 훨씬 더 적은 1GB 정도의 메모리 가상공간을 이용했고 초기에는 이것으로 충분했다. 어떤 프로세서들은 32비트 이상의 가상 주소공간을 이용할 수 있었으나 대부분은 32비트의 구조공간이 한계였다. 그러나 데이터베이스나 거대한 메모리 맵핑을 시도하는 애플리케이션인 경우 매우 부족한 공간이 되었기 때문에 확장이 필요했다. 64비트 운영체제에서는 더 많은 공간을 할당했다. 가상 메모리 공간은 실제의 램이 있건 없건 간에 사용자에게 커다란 메모리 공간을 사용하는 환상을 제공하며 Denning 같은 사람들에 의해 이론이 확립된 후 운영체제의 중요한 부분이 되었다. 필자는 가상 메모리에 대해 본지 2002년 8월호의 「운영체제 오디세이」에서 설명한 적이 있다(지금 생각해보면 부족한 부분이 많은 글이었다). 운영체제에서 가상 메모리를 다루는 큰 틀은 크게 두 가지로 나누어 설명할 수 있다. 첫 번째는 MMU(Memory Management Unit)와 관련된 부분이고 다른 하나는 가상 메모리를 백업하는 시스템(‘backing storage’라고도 하며 주로 파일 시스템이다)과의 상관관계로 나눌 수 있다. MMU와의 관계 가상 메모리 공간은 우선 MMU와 밀접한 관계가 있다. 64비트의 MMU라고 해서 32비트 프로세서와 완전히 다른 것은 아니며 거의 같다고 할 수 있다. 이들은 모두 32비트의 유산을 물려받았다. 아무튼 이상적인 가상 주소공간은 이른바 ‘크고 희박한(large and sparse)’ 것이라고 한다. 전체적으로는 큰 공간을 제공하고 그 안의 메모리를 차지하고 있는 요소들은 가상공간에서 가급적 멀리 떨어져 있어야 한다. 64비트 공간은 4GB 영역의 공간이 4GB 배만큼 더 있는 것이니까 당분간은 부족하지 않을 것 같다. 모든 프로세서는 전부 다른 MMU를 갖고 있고 접근 방법도 다르다. 이 부분에 대해서는 B. Jacob의 「Virtual memory in contem porary microprocessors」라는 정말 좋은 글이 있는데 몇 년 전의 글이지만 관심이 있는 독자들은 읽어보기 바란다. 저자는 몇 종류의 중요한 프로세서의 MMU와 관련된 구조를 비교하고 분석했다(TLB와 관련된 부분은 U.Vahalia의 「Unix Internals」와 관련하여 살펴보면 도움이 될 것이다. 일반적으로 TLB에 관련된 부분은 32비트에서도 상당히 어려운 부분이다). IA-64는 B. Jacob이 글을 쓸 때는 존재하지 않던 아키텍처라서 비교 대상에서 빠진 것이 아쉽다. IA-64로 본 64비트 패러다임 IA-64는 매우 다양한 메모리 구성을 지원하고 있기 때문에 설명이 어렵기도 하다. 많이 인용되는 인텔의 자료 중 「Unveiling the IA-64 Architecture for System Software」라는 글은 매우 깔끔하게 IA-64의 구조를 요약하고 있다(http://www.intel.com/design/itanium/ archSysSoftware/). 이 글에서 아이테니엄의 가상 메모리 공간에 관한 내용은 다음과 같이 나누어 정리하고 있다. ◆ 프로세스 주소공간(Process Address Space) ◆ 시스템 주소공간(System Address Space Management) ◆ 가상주소변환(l Virtual Address Translation TLB and Page table) ◆ 유연한 객체공유모델(Flexible Object Sharing Model) IA-64의 프로세스 주소공간은 각각 64비트 공간으로 설정할 수 있다. <그림 1>이 가장 기본적인 주소공간이다. 프로세스 주소공간은 각 프로세스 별로 독립적이다. 다른 말로 하면 개별적인 프로세스마다 64비트 공간을 모두 사용할 수 있다는 것인데 이 공간에 text , heap , bss 그리고 stack이 할당된다. IA-64 리눅스는 이 공간을 8개로 나누어 사용하고 있다. <그림 1> IA-64의 프로세스 주소공간 시스템 주소공간은 커널과 내부 설비가 사용하는 메모리이다. 이 공간 역시 내부적으로 64비트 공간을 설정할 수 있는데 이 공간은 이른바 영역(region : 유닉스의 영역구조와 비슷하지만 이것은 프로세서 내부에 있는 구조이다)을 이용하여 이 공간을 수많은 영역으로 나눌 수 있다(<그림 2>). 각 프로세스 별로 다른 영역들을 자신에게 맞게 맵핑할 수 있고 이들을 공유할 수도 있다. 운영체제가 잘 설계되고 영역이 여러 프로세스나 쓰레드에서 잘 공유될 수 있다면 매우 효율적인 자원공유라는 목표를 달성할 수 있을 것이다. <그림 2> IA-64의 시스템 메모리와 영역 구조 IA-64의 영역구조가 새로운 것처럼 보이지만 이들은 새로운 것이 아니다. IBM의 RS/6000(나중에 파워PC에 영향을 미친다)과 비슷한 시기에 발표되었던 HP의 PA-RISC의 고전적인 가상 메모리 구성방법이 IA-64에도 다시 적용된 것이다. 이 부분은 Precision Architecture의 가상 메모리에 관한 문헌들에 나오는 부분들이다. PA-RISC과 IA-64는 많은 유사성이 있는데 PA-RISC에서는 메모리 관리부분이 조금 특이했다. 메모리 관리에는 2가지 또는 3가지의 접근 방법이 있었다. MMU가 가상공간을 실제 주소로 구현할 때 IA-32에서는 페이지 테이블이라는 방법을 사용했고 다른 CISC들도 이런 방법을 사용했다(<그림 3>). 이 방법은 구현이 쉽기 때문에 많은 운영체제에서 사용했다. 단점이라면 가상공간이 넓은 경우 사용하지 않는 부분에 대해서도 페이지 테이블을 유지해야 되므로 페이지 테이블의 오버헤드가 너무 커지는 단점이 있다. 페이지 테이블은 간단히 말하면 가상공간의 페이지 테이블을 만들고 실제의 메모리와 대응시키는 방법이다. <그림 3> 이지 테이블 방식의 가상메모리 관리로 가장 많이 쓰이는 방법이다. 64 비트에서는 3레벨 또는 그 이상의 페이지 테이블을 사용한다. 반대의 패러다임은 역 페이지 테이블을 이용하는 방법으로 RS-6000과 파워PC에서 사용한 것이다, 가상공간이 아니라 실제 존재하는 메모리의 페이지 테이블을 만들고 이것을 가상 메모리에 대응시키는 것이다. 역 페이지 테이블은 직관적이긴 하나 문제가 없는 것도 아니다. 예를 들면 새로운 페이지 테이블을 할당하거나 변환 실패가 증가할 때의 갱신 오버헤드가 증가하는 것 같은 문제가 있다. 다른 패러다임으로는 MIPS R3000처럼 TLB(translation lookaside buffer)를 이용하여 IA-32에서처럼 수많은 페이지 테이블을 관리하는 번거로움에서 벗어날 수 있도록 하는 방법으로 단점이 없는 것도 아니다. 그러나 관리해야 하는 주소 공간이 커지고 페이지 테이블을 따로 관리해야 하는 오버헤드가 커지면 좋은 방법이 될 수도 있다. 필자가 설명한 부분은 Uresh Vahalia의 「Unix Internals」 13장에 장단점이 자세히 나오며 B. Jacob의 글에서는 실제의 MMU 구조를 비교하며 자세히 설명되는 부분이다. IA-64에서는 PA-RISC에서의 방법과 기존의 페이지 테이블을 이용한 관리방법도 같이 있는데 이들을 조합하고 구현하는 것은 운영체제 설계자의 몫이다. <그림 4> 역 페이지 테이블 방식의 MMU구조이다. 이 방식은 거대한 페이지 테이블을 유지하지 않고 물리적 메모리(RAM)의 페이지 테이블 만을 유지한다. TLB와 MMU 그리고 페이지 테이블 방식의 상호 관계에 대한 해묵은 논쟁은 32비트가 등장한 80년대부터 논란의 여지가 많은 주제였으나 IA-64는 이들을 모두 포함한다. 64비트이긴 하지만 별반 새로운 것은 아니다. IA-64의 두 가지 방식의 혼재가 혼란스럽기는 하지만 운영체제의 포팅이 좀더 용이하다는 점도 간과할 수 없다. 과거에는 페이지 테이블을 이용한 MMU 관리가 대세를 이루었으나 주소공간이 커지면서 역 페이지 테이블을 이용한 MMU 관리도 점차 증가할 것이다. 아직까지는 문서화된 자료들에서는 기존의 운영체제의 큰 틀에서 벗어나지 않고 있다. 책으로 출판된 IA-64 리눅스 커널 같은 자료에서도 기존의 메모리 관리 방침의 큰 골격을 그대로 이용하고 있고 솔라리스의 64비트 버전도 마찬가지다(IA-64의 리눅스 커널의 홈페이지 참조). 프로세서에서 아무리 큰 발전이 있더라도 운영체제의 대대적인 구조변경으로까지 반영되려면 많은 노력이 필요하며 기존의 골격을 결코 쉽게 포기하지는 않는다. 마이크로 커널이라고 해도 64비트로의 이행은 만만한 일이 아니다. 참고로 맥 OS X은 마이크로 커널 구조인데 64비트가 되었어도 과거의 커널 구조는 그대로 유지하고 있다. 마크(Mach)의 VM 구조를 최적화한 형태이긴 하지만 그대로 유지하고 있는 것이다. 64비트 프로세서에 최적화된 운영체제의 새로운 지도를 작성하려면 시간이 더 필요한 것이다. 놀라운 성능의 프로세서를 사용하는 64비트 머신이라도 실제로는 향상된 능력의 전부를 사용하는 것도 아니고 그렇게 대단한 일이 아니다. 성능보다는 기능성에서 또한 앞으로의 발전 가능성에 대한 기대를 갖는 편이 더 나을 것이다. <그림 5> 맥 OS X의 구조 데이터를 처리하는 방식이 변한다 여러 개의 검증된 64비트 프로세서와 비교적 새로 등장한 IA-64 그리고 AMD의 해머같이 확장된 프로세서는 앞으로 시장의 점유를 놓고 경쟁할 것이고 새로운 64비트 운영체제와 애플리케이션이 등장할 것이다. 이번 글에서는 운영체제에서 가장 큰 변화를 겪을 것으로 예상되는 가상 메모리 부분에 대해 피상적으로 설명했다. 파일 시스템이나 통신 같은 부분은 64비트라고 해도 크게 바뀌지 않을 것이다. 그런데 가상 메모리는 다르다. 지금까지는 기대할 수 없던 거대한 데이터를 메모리에 맵핑하고 관리할 수 있게 되면 애플리케이션이나 미들웨어에서 버퍼와 캐시를 할당하기 위해 기울였던 노력은 운영체제로 넘어가게 된다. 하나의 거대한 파일을 커다란 메모리 공간으로 맵핑하고 이 공간의 관리는 운영체제가 맡는다. 운영체제는 새로운 MMU의 능력을 이용해서 최소한도의 오버헤드로 커다란 주소공간을 관리한다, 데이터베이스나 멀티미디어 애플리케이션들은 중대한 변화를 맞이하게 될 것이 분명하다. 프로세서의 주소공간에서 본다면 테라바이트도 작은 사이즈에 속할 날이 얼마 남지 않은 것 같다. 이미 윈도우의 IA-64 버전도 16TB의 주소공간을 기본적으로 지원한다. 물론 VM은 MMU 만으로 이뤄지지 않는다. 거대한 파일을 저장하기 위해 지금보다 더 개량된 파일 시스템이라든가 더 가벼운 IPC 그리고 VM을 효율적으로 구현하기 위한 쓰레드 관리 같은 것이 계속 추가될 것이다. 이번 글에는 지면상 아예 포함하지 않았으나 캐시 갱신의 완전성 관리(특히 SMP의 경우) 같은 더 복잡한 내용이 더 남아있다. 단순히 VM의 관리만을 놓고도 진보를 이루어야 할 복잡한 내용들이 너무나 많다. 프로세서는 32비트 시절의 많은 유산들을 청산하고 64비트가 되었으나 운영체제는 32비트의 골격을 유지하면서 64비트로 서서히 넘어가고 있다. 그러나 64비트 운영체제는 초기단계라고 해도 32비트에서는 시도하지 못했던 거대한 주소공간을 갖게 되었다. 64비트 운영체제가 조금 더 흔해지게 되면 데이터를 다루는 패러다임 자체에 변화가 올 것이고 사람들이 어떤 대상을 생각하는 방법이 바뀌기 시작하면 그때는 큰 변화가 올 것이다. @ * 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.