월: 2009 4월

메인프레임과 리눅스

본 내용은 IBM 기술 게시판에 게재된 내용 중에 메인프레임과 리눅스의 관계에 대한 부분을 발췌하였습니다.

1. 레지스터의 사용

레지스터는 CPU밖에 있는 메모리보다 당연히 고속으로 access를 할 수 있습니다. 하지만 반도체 기술 상의 난제로 인해 예나 지금이나 한정된 수의 레지스터만을 장착하게 됩니다. CPU의 성능이란 결국 한정된 레지스터를 얼마나 효율적으로 사용하느냐에 달려있다고 해도 과언이 아닙니다. Clock speed가 3배, 4배가 되어도 CPU의 성능이 3배는 커녕 2배도 안되는 이유는 바로 여기에 있습니다.
또한 레지스터는 CPU의 명령셋과 밀접한 관련이 있어 CPU의 아키텍쳐별로 사용하는 방식도 달라집니다. 현재의 64bit 방식 IBM 메인프레임(System z)은 16개의 범용 레지스터와 16개의 IEEE 부동 소수점 레지스터, 16개의 제어 레지스터와 16개의 Access Register를 갖고 있습니다.

메인프레임에서 리눅스를 가동시키면 리눅스가 이들 64개의 레지스터를 정해진 용도로만 사용하게 됩니다. 예를 들어 범용 레지스터인 R2는 복귀값, R14는 복귀 어드레스, R15는 스택 포인터 대용으로 사용합니다. 리눅스에서 레지스터를 사용하는 방식에 대해서는 리눅스의 사양서라고 할 수 있는 ELF(Executable and Linking Format) ABI Supplement라는 문서에 게재되어 있습니다.

원래 메인프레임 상의 어셈블러에서는 R15를 복귀값이나 복귀 어드레스용으로 쓰는 것이 원칙이었으나, 메인프레임에는 수 십년간 Stack이라는 개념이 없었기 때문에, Stack을 에뮬레이션하기 위해 Stack Pointer로서 R15를 사용하고 있습니다.

다른 CPU 아키텍쳐와 비교하면 레지스터가 많지 않습니다. 그러나 메인프레임은 CISC 방식 설계이기 때문에 다양하며 기능이 뛰어난 명령셋을 구비하여 레지스터 자체가 많이 필요없습니다. 따라서 44년전이나 지금이나 범용 레지스터의 수는 16개로 변함이 없습니다.

2. 메인프레임에는 없었던 명령셋

다른 CPU 아키텍쳐에는 있으나 메인프레임에는 없었던 명령으로서는 상대 점프 명령과 Stack 명령을 들 수 있습니다. IA32 아키텍쳐에서는 자주 쓰이는 명령입니다. 상대 점프 명령은 점프하는 거리가 짧으면 명령어 길이를 짧게 할 수 있는데다가 절대 주소 번지를 일일이 신경쓸 필요가 없는 장점이 있어 자주 쓰이는 명령셋입니다.
메인프레임은 수 십년 전부터 메모리 자체가 가상화되어 관리되므로 메모리 Map의 Relocation이 필요없었습니다. 그러나 유닉스나 리눅스에서는 코드 자체가 언제나 메모리 Relocation이 가능한 Binary이어야만 하므로, 메인프레임 역시 1997년부터 유닉스와 리눅스를 지원하기 위해 상대 점프 명령을 추가하였습니다.

Stack은 일시적인 대피용 저장 장소로 자주 쓰이며, 1명령만으로 메모리 조작과 어드레스 조작을 해주므로 장점이 많습니다. 특히 C 컴파일러로 작성된 코드는 Stack 명령을 자주 쓰는 경향이 있습니다. 그러나 주지의 사실처럼 Stack Overflow등과 같이 코드 취약성에 그대로 노출되어 있습니다. 현재에는 시스템의 관리자 권한을 얻기 위한 1차 공격 목표가 되고 있습니다.
불행인지 다행인지 메인프레임은 2005년까지는 Stack 명령 자체가 없었기에 이런 취약성은 없었습니다. Stack의 편리함보다는 메모리 관리의 취약성을 더 중시했기 때문입니다. 따라서 Stack을 에뮬레이트하여 대행하다보니 유닉스와 리눅스 어플리케이션, 특히 C기반 코드를 가동시키면 절대로 퍼포먼스가 좋게 나올리가 없었습니다. 또한 같은 기능의 코드를 작성해도 메인프레임에서는 에뮬레이트를 위한 부분이 추가되어 코드 자체가 길어지는 문제도 있었습니다.

3. 메모리 관리 – 64비트 어드레싱

메인프레임은 이미 2000년부터 완전한 64bit 메모리 어드레싱을 하고 있습니다만, 리눅스에서 64비트 어드레싱을 하는 경우, 메인프레임 OS와는 달리, Page Table이나 제어 블럭 등 관리용 메모리만으로 엄청난 용량을 소비할 수 밖에 없고, DAT(Dynamic Address Translation)에 의한 주소 변환 작업도 프로세스 수가 급격히 늘어나서 메모리 access time이 DISK access time 수준으로 악화됩니다.
이러한 문제점을 해결하면서 대량 메모리 어드레싱의 장점도 함께 이용하기 위해, 메인프레임 상에서 리눅스를 가동하는 경우, 42비트 어드레싱을 하게 되어 있습니다. (2 x 42승 = 2 x 2 승 TeraByte = 4 TB까지 메모리 확장)
이는 리눅스 커널 내의 파라미터를 변경하여 조작한 것입니다. 아래 그림에서 64bit DAT와 42bit DAT를 비교한다면, 42bit DAT를 사용하면, Region-1과 Region-2를 0으로 하여 변환 Process를 생략할 수 있기 때문에 전체 5단계가 걸리는 process가 3단계로 축소됩니다. 이로서 메모리 access의 고속화를 이룰 수 있습니다.

64bit DAT

64bit DAT

42bit DAT

42bit DAT

4. 메모리 관리 – Context Switching

리눅스는 멀티 태스킹 OS이므로 다수의 프로세스가 가상 메모리상의 다수의 어드레스 공간에서 동시에 병행하여 실행됩니다. 그러나 실제 하드웨어의 CPU수는 많아야 10여개인 경우가 대부분이기 때문에 가동 중인 프로세스 수보다는 항상 적을 수 밖에 없습니다. 따라서 CPU를 시분할방식으로 나누어 다수의 프로세스를 실행시킵니다. 이 때 프로세스를 전환하는 처리를 Context Switching이라고 하며 리눅스 커널의 중요한 임무 중의 하나가 됩니다.
Context Switching이 일어나면, 당연히 현재 처리 중인 프로세스의 context를 대피시켰다가 다시 돌아와야되므로 가상 어드레스 공간사이에서 Data의 copy가 일어나게 됩니다. 이 양이 많아질수록 커널의 오버헤드가 커지게 되며, 정도가 심할 경우 시스템이 갑자기 slow down하는 현상이 발생하게 됩니다.
메인프레임에서 운영되는 리눅스에서는 이를 고속화하기 위해 Access Register를 사용합니다. 이 레지스터는 가상 메모리 공간 사이에 처리가 가능한 특수 레지스터로서, Base Register로서 사용할 수 있습니다. 같은 가상 메모리 공간내에서의 Data 이동 명령은 얼마든지 간단하게 고속으로 할 수 있지만, 서로 다른 가상 메모리 공간 사이의 Data 이동 명령은 HW 명령으로 구현하기에도 그리 간단치 않습니다. 메인프레임의 경우에는 이를 Access Register를 사용하여 2개의 가상 어드레스 공간 자체를 Point하여 copy하는 방식으로 몇 개의 HW 명령만으로 처리를 완결할 수 있습니다. 결과적으로 Context Switching에 의한 오버헤드가 거의 없이 고부하 환경에서도 안정가동을 이룰 수 있습니다. 이는 다수의 리눅스 이미지를 가동시키면서도 CPU 부하를 80%이상으로 유지시킬 수 있는 메인프레임 환경에서 중요한 기술 중의 하나입니다.

※ 보다 상세한 내용을 원하시는 분께서는 z/Architecture Principles of Operation (SA22-7832) 문서를 참고하시기 바랍니다.

Advertisements

[책] OPENSOURCES

zLinux와 직접적인 관련은 없지만, 오픈소스에 대한 전반적인 이야기이므로, 한번쯤 읽어봐도 좋을 책이어서 소개합니다. 온라인 책이고요, 에릭 레이먼드 아저씨가 쓴 책입니다. 즐겁게 읽으세요~ 🙂

. 해커문화의 짧은 역사
. 버클리 유닉스의 20년: AT&T 소유에서 자유로운 재배포가 가능하기까지
. 인터넷 엔지니어링 태스크 포스
. GNU 운영체제와 자유 소프트웨어 운동
. 시그너스 솔루션스의 미래
. 소프트웨어 공학
. 첨단의 리눅스
. 무료공개: 레드햇 소프트웨어사의 새로운 경제 모델과 산업 발전에의 기여
. 근면, 인내, 그리고 겸손
. 비즈니스 전략으로서의 오픈소스
. 오픈소스에 대한 정의
. 하드웨어, 소프트웨어, 인포웨어
. 소스를 자유롭게: 모질라 이야기
. 해커들의 반란

z/VM에 대한 소개

z/VM
벌써 출시된 지 35년 40년을 훌쩍 넘겨버린 오래된 IBM의 운영체제입니다. 2000년 전까지만 하더라도 거의 사라져가는 운영체제 중에 하나였다고 해도 과언이 아닐겁니다. 하지만, Linux가 포팅되어 운영되기 시작하면서 다시금 부활(?)하게 된 운영체제입니다. Linux가 본격적으로 포팅되고 발표된 2000년 이후의 z/VM은 거의 Linux를 위한 가상화 플랫폼으로 거듭날 정도로 Linux와 관련된 많은 기능들이 추가되고, 향상되어왔습니다.

솔직히 검은 바탕에 초록색 글자의 향수(?)를 느끼기에는 너무도 어색하고, 불편하기만한 콘솔 앞이지만… ^^

z/VM에 대한 소개자료입니다. 한번 쓰윽~ 훑어보시는 것도 좋을 듯 싶어 올립니다.

z/VM Introduction

메인프레임의 역사와 진화

IBM Jim Elliott 아저씨가 참 많은 자료를 만들고, 발표했죠. ^^ 역시 SHARE에서 발표한 자료입니다. System z – 메인프레임 – 의 역사와 그 진화과정에 대한 내용입니다. 뭐… 그래도 이런 자료 하나는 있어야할 것 같아서… 🙂

The History and Evolution of IBM Mainframes

— 2010-05-11 파일을 최신 것으로 변경했습니다. 🙂