마하(커널)

Mach (kernel)
마하
개발자리처드 라시드
아비 테바니안
초기출시1985년; 38년전 (1985)
안정적 해제
3.0 / 1994; 29년 전(1994)
플랫폼IA-32, x86-64, MIPS, ARM32, Aarch64, m88k
유형마이크로커널
웹사이트마하 프로젝트

마하(Mach, /m ɑːk/)는 카네기 멜론 대학교에서 운영 체제 연구를 지원하기 위해 Richard Rashid와 Avie Tevanian에 의해 개발된 커널입니다.마하는 종종 마이크로커널의 초기 예 중 하나로 여겨집니다.그러나 모든 버전의 마하가 마이크로커넬인 것은 아닙니다.마하의 파생 모델은 GNU 허드의 운영 체제 커널과 맥OS, iOS, 아이패드OS, tvOS, 와치OS에 사용되는 애플의 XNU 커널의 기초입니다.

카네기 멜론의 프로젝트는 1985년부터 1994년까지 진행되었으며,[2] 진정한 마이크로커널인 마하 3.0으로 끝이 났습니다.마하는 유닉스의 BSD 버전에서 커널을 대체하기 위해 개발되었기 때문에 새로운 운영 체제를 설계할 필요가 없습니다.마하와 그 파생 모델은 다수의 상용 운영 체제 내에 존재합니다.여기에는 이전의 비마이크로 커널 마하를 주요 구성 요소로 통합한 XNU 운영 체제 커널을 사용하는 것이 모두 포함됩니다.마하 가상 메모리 관리 시스템 또한 4.4에 채택되었습니다.CSRG의 BSD 개발자들에 의한 BSD는 FreeBSD와 같은 현대의 BSD 파생 유닉스 시스템에 등장합니다.[3]

마하는 카네기 멜런의 액센트 커널의 논리적 후계자입니다.마하 프로젝트의 수석 개발자인 Richard Rashid는 1991년부터 마이크로소프트에서 일하고 있으며, 마이크로소프트 리서치 부서를 설립했습니다.원래 마하 개발자 중 한 명인 Avie Tevanian은 이전에 NeXT의 소프트웨어 책임자였으며, 2006년 3월까지 Apple Inc.의 최고 소프트웨어 기술 책임자였습니다.[4][2]

역사

이름.

개발자들은 비 오는 피츠버그의 진흙 웅덩이를 자전거를 타고 점심을 먹어야 했고, 테바니안은 "머크"라는 단어가 멀티유저(또는 멀티프로세서 유니버설) 통신 커널의 백로닉을 형성할 수 있다고 농담했습니다.이탈리아 CMU 엔지니어 다리오 주이스는 나중에 프로젝트 리더인[5] 릭 라시드에게 프로젝트의 현재 제목에 대해 물었고, "MUCK"을 답으로 받았습니다.IPA: [m ʌk] 그는 이탈리아 알파벳에 따라 마하처럼 썼습니다.라시드는 주세우스의 철자 "마흐"를 너무 좋아해서 널리 퍼졌습니다.[6]: 103

유닉스 파이프

원래 유닉스 운영 체제의 핵심 개념은 파이프(pipe)라는 개념이었습니다.파이프는 데이터를 프로그램에서 프로그램으로 구조화되지 않은 바이트 스트림으로 이동할 수 있게 해주는 추상화입니다.파이프를 사용하여 사용자(또는 프로그래머)는 여러 프로그램을 연결하여 작업을 완료하고 여러 개의 작은 프로그램을 차례로 통해 데이터를 공급할 수 있습니다.이는 전체 작업을 처리할 수 있는 단일 대형 프로그램을 필요로 하거나, 파일을 사용하여 데이터를 전달해야 하는 당시의 일반적인 운영 체제와는 대조적이었으며, 이는 리소스 비용과 시간이 많이 소요되었습니다.

파이프는 기본 입출력 시스템을 기반으로 제작되었습니다.또한 이 시스템은 드라이버가 작업이 완료되기를 기다리는 동안 주기적으로 "차단"될 것으로 예상되는 모델에 기반을 두고 있었습니다.예를 들어, 프린터 드라이버가 라인 프린터로 한 줄의 텍스트를 보낸 다음 해당 라인의 인쇄를 완료할 때까지 아무 작업도 수행하지 않을 수 있습니다.이 경우 드라이버는 차단되었음을 표시하고, 운영 체제는 프린터가 더 많은 데이터를 준비할 준비가 되었다고 표시할 때까지 다른 프로그램을 실행하도록 허용합니다.파이프 시스템에서 제한된 자원은 메모리였고, 한 프로그램이 파이프에 할당된 메모리를 채우면 자연스럽게 차단됩니다.일반적으로 이 경우 소모성 프로그램이 실행되어 파이프를 다시 비웁니다.다음 프로그램에서 사용하기 전에 전체 파일을 읽거나 써야 하는 파일과 달리 파이프는 프로그래머의 개입 없이 여러 프로그램 간의 데이터 이동을 단편적으로 수행합니다.

그러나 메모리 버퍼에 파이프를 구현하면 데이터를 프로그램에서 프로그램으로 복사해야 하므로 시간이 많이 걸리고 리소스가 많이 소요되는 작업입니다.이로 인해 파이프 개념은 대부분의 장치 드라이버와 같이 빠른 턴어라운드 또는 낮은 지연 시간이 필요한 작업에 적합하지 않았습니다.운영 체제의 커널과 대부분의 핵심 기능은 대신 하나의 대형 프로그램으로 작성되었습니다.컴퓨터 네트워킹과 같은 새로운 기능이 운영 체제에 추가되었을 때, 커널의 크기와 복잡성 또한 커졌습니다.

신개념

유닉스 파이프는 작은 상호작용 프로그램으로 임의로 복잡한 솔루션을 구축하는 데 사용할 수 있는 개념적인 시스템을 제공했습니다.이러한 소규모 프로그램은 개발 및 유지보수가 용이했으며 프로그래밍 및 디버깅을 단순화하는 명확한 인터페이스를 갖추고 있었습니다.이러한 특성은 작은 크기와 버그가 없는 성능이 매우 중요한 장치 드라이버에게 더욱 유용합니다.작은 상호작용 프로그램을 기반으로 커널 자체를 모델링하려는 욕구가 강했습니다.

운영 체제를 뒷받침하는 파이프와 같은 시스템을 사용한 최초의 시스템 중 하나는 로체스터 대학교에서 개발된 알레프 커널입니다.이것은 본질적으로 공유 메모리 구현인 포트의 개념을 도입했습니다.알레프에서는 커널 자체가 메모리와 포트를 포함한 하드웨어에 대한 액세스를 제공하는 것으로 축소되었지만 포트 시스템을 사용하는 기존의 프로그램은 장치 드라이버에서 사용자 프로그램에 이르기까지 모든 동작을 구현했습니다.이 개념은 커널의 크기를 크게 줄였고, 사용자가 단순히 드라이버를 로드하고 런타임에 함께 연결하는 것만으로 다양한 드라이버를 실험할 수 있게 했습니다.이를 통해 새로운 운영 체제 코드를 개발할 때 문제가 크게 완화되었으며, 그렇지 않으면 일반적으로 기계를 다시 시작해야 했습니다.작은 커널과 외부 드라이버의 일반적인 개념은 마이크로커널로 알려지게 되었습니다.

Alph는 Data General Eclipse 미니 컴퓨터에 구현되었으며 이 미니 컴퓨터에 단단히 묶여 있었습니다.이 기계는 프로그램 간에 메모리를 복사해야 했기 때문에 성능 오버헤드가 컸기 때문에 이상적인 것과는 거리가 멀었습니다.그것은 또한 꽤 비쌌습니다.그럼에도 불구하고, Aleph는 기본 시스템이 건전하다는 것을 증명했고, 초기 이더넷 인터페이스를 통해 메모리를 복사함으로써 컴퓨터 클러스터링을 증명했습니다.

이 무렵, 새로운 세대의 중앙 프로세서(CPU)가 출시되어 32비트 주소 공간과 메모리 관리 유닛(MMU)에 대한 (초기에는 옵션으로) 지원을 제공했습니다.MMU는 가상 메모리 시스템을 구현하는 데 필요한 명령을 다양한 프로그램에 의해 사용되는 메모리 페이지를 추적함으로써 처리했습니다.이를 통해 가상 메모리 시스템에서 제공하는 copy on write 메커니즘을 사용하여 포트 개념에 대한 새로운 해결책을 제시했습니다.프로그램 간에 데이터를 복사하는 대신 MMU가 동일한 메모리에 액세스할 수 있도록 지시하는 데 필요한 데이터만 전송하면 되었습니다.이 시스템은 프로세스 간 통신 시스템을 획기적으로 더 높은 성능으로 구현할 것입니다.

이 개념은 Aleph를 PERQ 워크스테이션에 적용하고 카피 온 라이트(copy-on-write)를 사용하여 구현한 Carnegie-Mellon(카네기-Mellon은 Aleph를 PERQ 워크스테이션에 적용했습니다.포트는 성공적이었지만, 결과로 나온 Accent 커널은 기존 소프트웨어를 실행하지 않았기 때문에 실용성이 제한적이었습니다.게다가 액센트는 알레프가 이클립스에 그랬던 것처럼 PERQ에 단단히 묶여 있었습니다.

마하

이러한 실험 커널과 마하 사이의 주요한 변화는 기존 4.2 버전을 만들기로 결정한 것입니다.액센트 메시지 전달 개념에 BSD 커널을 다시 구현했습니다.이러한 커널은 기존의 BSD 소프트웨어와 바이너리 호환이 가능하여 시스템을 유용한 실험 플랫폼이면서 일상적인 용도로 즉시 유용하게 사용할 수 있습니다.또한, 새로운 커널은 처음부터 여러 프로세서 아키텍처를 지원하도록 설계될 것이며, 이기종 클러스터를 구성할 수도 있습니다.시스템을 최대한 빨리 가동시키기 위해, 시스템은 기존의 BSD 코드부터 시작하여 프로세스간 통신 기반(IPC 기반) 프로그램으로 조금씩 재구현함으로써 구현될 것입니다.따라서 마하는 기존의 UNIX 시스템과 유사한 단일 시스템으로 시작하여 시간이 지남에 따라 마이크로커널 개념으로 더욱 진화할 것입니다.[4]

마하는 깨끗하게 정의된 UNIX 기반의 휴대성이 뛰어난 Accent를 만들기 위한 노력으로 시작했습니다.그 결과 일반적인 개념의 짧은 목록이 나타납니다.[7][8]

  • "태스크"는 "threads"가 실행될 수 있도록 하는 시스템 리소스 집합으로 구성된 객체입니다.
  • "thread"는 하나의 실행 단위이며, 작업의 컨텍스트 내에 존재하며 작업의 리소스를 공유합니다.
  • "포트"는 작업 간 통신을 위한 보호된 메시지 큐이며 작업은 각 포트에 대한 송신 권한(권한)과 수신 권한을 소유합니다.
  • "messages"는 유형화된 데이터 개체의 집합이며, 포트로만 전송할 수 있으며, 태스크나 스레드는 특별히 포함되지 않습니다.

마하는 액센트의 IPC 개념을 기반으로 개발되었지만, 시스템을 본질적으로 훨씬 더 유닉스적인 형태로 만들었고, 심지어 수정 없이 유닉스 프로그램을 실행할 수 있었습니다.이를 위해 마하는 양방향 IPC의 각 엔드포인트를 나타내는 포트의 개념을 도입했습니다.포트는 UNIX에서 파일과 같은 보안 및 권한을 가지고 있으므로 매우 UNIX와 유사한 보호 모델을 적용할 수 있었습니다.또한, 마하는 사용자 공간 프로그램이 하드웨어와 상호 작용하는 것과 같은 것들을 처리할 수 있도록 하기 위해 운영 체제에만 주어진 권한을 모든 프로그램이 처리할 수 있도록 했습니다.

Mach와 UNIX에서 운영 체제는 다시 주로 유틸리티의 집합체가 됩니다.유닉스와 마찬가지로 마하는 하드웨어를 처리하는 드라이버 개념을 유지하고 있습니다.따라서 현재 하드웨어의 모든 드라이버가 마이크로커널에 포함되어야 합니다.하드웨어 추상화 계층 또는 엑소커넬을 기반으로 하는 다른 아키텍처는 드라이버를 마이크로커널 밖으로 이동시킬 수 있습니다.

UNIX와의 주요 차이점은 유틸리티가 파일을 처리하는 대신 모든 "태스크"를 처리할 수 있다는 것입니다.더 많은 운영 체제 코드가 커널 밖으로, 사용자 공간으로 옮겨졌고, 그 결과 훨씬 더 작은 커널과 마이크로커널이라는 용어가 등장했습니다.기존 시스템과 달리 마하 프로세스, 즉 "태스크"에서는 여러 스레드로 구성될 수 있습니다.이것이 현대 시스템에서는 일반적이지만, 마하는 이러한 방식으로 작업과 스레드를 정의한 최초의 시스템이었습니다.커널의 업무는 본질적으로 운영 체제에서 "유틸리티"를 유지 관리하고 하드웨어에 대한 액세스를 예약하는 것으로 축소되었습니다.

포트의 존재와 IPC의 사용은 아마도 마하와 기존 커널의 가장 근본적인 차이점일 것입니다.UNIX에서 커널을 호출하는 것은 시스템 호출 또는 트랩이라는 이름의 연산으로 구성됩니다.이 프로그램은 라이브러리를 사용하여 메모리의 잘 알려진 위치에 데이터를 배치한 다음 오류 유형인 오류를 발생시킵니다.시스템을 처음 시작할 때 커널은 모든 장애의 "핸들러"가 되도록 설정됩니다. 따라서 프로그램이 장애를 일으키면 커널은 이를 인계받아 전달된 정보를 조사한 다음 명령을 수행합니다.

마하 하에서는 IPC 시스템이 대신 이 역할에 사용되었습니다.시스템 기능을 호출하기 위해 프로그램은 커널에 포트에 대한 액세스를 요청한 다음 IPC 시스템을 사용하여 해당 포트로 메시지를 전송합니다.메시지를 전송하려면 시스템 호출이 필요하지만, 다른 시스템에서 시스템 기능을 요청하려면 시스템 호출이 필요하지만, 마하에서는 메시지를 전송하는 것이 커널의 거의 모든 작업입니다. 실제 요청을 처리하는 것은 다른 프로그램의 몫입니다.

스레드 및 동시성 지원은 이제 작업이 메시지 처리 중에 마하가 동결 및 해제할 수 있는 여러 코드 스레드로 구성되었기 때문에 IPC 메커니즘을 사용한 메시지 전달에 도움이 되었습니다.이를 통해 대부분의 마하 메시지에서와 같이 공유 메모리를 직접 사용하거나 필요에 따라 다른 프로세서에 메시지를 복사하기 위한 코드를 추가하여 시스템을 여러 프로세서에 분산시킬 수 있었습니다.기존 커널에서는 구현하기가 어렵습니다. 시스템은 다른 프로그램이 다른 프로세서의 동일한 메모리에 쓰려 하지 않도록 해야 합니다.그러나 메모리 액세스를 위한 프로세스인 마하 포트는 이를 잘 정의하고 구현하기 쉽도록 만들어 해당 시스템에서 일등 시민이 되었습니다.

IPC 시스템은 초기에 성능 문제가 있었기 때문에 영향을 최소화하기 위한 몇 가지 전략이 개발되었습니다.이전의 액센트처럼 마하는 하나의 공유 메모리 메커니즘을 사용하여 한 프로그램에서 다른 프로그램으로 메시지를 물리적으로 전달했습니다.메시지를 물리적으로 복사하는 것은 너무 느리기 때문에 마하는 기계의 메모리 관리 장치(MMU)에 의존하여 한 프로그램에서 다른 프로그램으로 데이터를 빠르게 매핑합니다.데이터를 쓰기 위해 데이터를 쓰는 경우에만 물리적으로 복사해야 합니다. 이 과정을 "쓰기 시 복사"라고 합니다.

또한 시스템을 구성하는 많은 프로그램 중 하나인 불량 데이터가 충돌하는 것을 방지하기 위해 커널에서 메시지의 유효성을 검사했습니다.포트는 UNIX 파일 시스템 개념을 기반으로 의도적으로 모델링되었습니다.이를 통해 사용자는 기존 파일 시스템 탐색 개념을 사용하여 포트를 찾을 수 있을 뿐만 아니라 파일 시스템에서와 같이 권한과 권한을 할당할 수 있었습니다.

그런 시스템 하에서 개발하는 것이 더 쉬울 것입니다.작업 중인 코드는 기존 도구를 사용하여 구축할 수 있는 기존 프로그램에 존재할 뿐만 아니라, 동일한 도구를 사용하여 시작, 디버깅 및 삭제할 수도 있습니다.모노커널을 사용하면 새로운 코드의 버그가 전체 기계를 다운시키고 재부팅이 필요한 반면 마하에서는 프로그램을 다시 시작하기만 하면 됩니다.또한 사용자는 필요한 기능을 포함하거나 제외하도록 시스템을 조정할 수 있습니다.운영체제는 단순한 프로그램 모음이었기 때문에 다른 프로그램처럼 단순히 실행하거나 삭제하는 것만으로 부품을 추가하거나 제거할 수 있었습니다.

마지막으로, 마하 하에서 이 모든 기능들은 의도적으로 극도로 플랫폼 중립적이 되도록 설계되었습니다.마하에서 텍스트 하나를 따옴표로 묶기

멀티프로세싱을 고려하지 않고 개발된 UNIX와 달리, 마하는 멀티프로세싱 지원을 전체에 통합합니다.또한 멀티프로세싱 지원은 공유 메모리 시스템에서부터 프로세서 간에 공유 메모리가 없는 시스템에 이르기까지 매우 유연합니다.마하는 하나에서 수천 개의 프로세서에 이르는 컴퓨터 시스템에서 작동하도록 설계되었습니다.게다가 마하는 다양한 컴퓨터 아키텍처에 쉽게 이식됩니다.마하의 핵심 목표는 이기종 하드웨어에서 작동할 수 있는 분산 시스템입니다.[9]

하지만 여러 가지 단점이 있습니다.비교적 일상적인 것은 항구를 찾는 방법이 명확하지 않다는 것입니다.UNIX 하에서 프로그래머들이 다양한 임무를 수행하기 위해 파일 시스템의 여러 "잘 알려진" 위치에 합의함에 따라 이 문제는 시간이 지남에 따라 해결되었습니다.이와 같은 접근 방식이 마하의 포트에도 적용되었지만, 마하 하에서는 운영 체제가 훨씬 더 유동적이며 항상 포트가 나타나고 사라집니다.포트와 그들이 대표하는 서비스를 찾는 어떤 메커니즘이 없다면, 이러한 유연성은 상당 부분 상실될 것입니다.

발전

마하는 처음에 기존 4.2에 직접 작성된 추가 코드로서 호스팅되었습니다.BSD 커널, 팀이 시스템을 완성하기 훨씬 전에 작업할 수 있게 해줍니다.작업은 이미 작동 중인 Accent IPC/port 시스템에서 시작하여 OS의 다른 핵심 부분인 태스크, 스레드 및 가상 메모리로 이동했습니다.부품이 완성됨에 따라 BSD 시스템의 여러 부분이 다시 작성되어 마하를 호출하고 4.3으로 변경되었습니다.이 과정에서 BSD도 만들어졌습니다.

1986년까지 시스템은 DEC VAX에서 자체적으로 실행할 수 있을 정도로 완성되었습니다.비록 실용적인 가치는 거의 없지만 마이크로커널을 만들겠다는 목표는 실현되었습니다.곧 IBM RT PC와 Sun Microsystems 68030 기반 워크스테이션용 버전이 출시되어 시스템의 휴대성을 입증했습니다.1987년까지 이 목록에는 앵콜 멀티맥스와 시퀀트 밸런스 머신이 포함되었으며, 멀티프로세서 시스템에서 마하의 실행 능력을 테스트했습니다.그 해에 공개 릴리스 1이 만들어졌고, 릴리스 2는 그 다음 해에 이어졌습니다.

이 기간 동안 "진정한" 마이크로커널에 대한 약속은 아직 전달되지 않았습니다.이러한 초기 마하 버전은 대부분 4.3을 포함했습니다.POE 서버로 알려진 시스템인 커널의 BSD로, 실제로 기반이 되는 UNIX보다 더 큰 커널이 탄생했습니다.그러나 UNIX 계층을 커널에서 사용자 공간으로 이동하여 더 쉽게 작업할 수 있고 완전히 교체할 수도 있습니다.불행하게도 성능이 큰 문제임이 입증되었고, 이 문제를 해결하기 위해 수많은 아키텍처 변경이 이루어졌습니다.유연하지 않은 UNIX 라이센스 문제도 연구자들을 괴롭혔고, 따라서 라이센스가 없는 UNIX와 유사한 시스템 환경을 제공하기 위한 초기의 노력은 계속해서 사용되었으며, 이는 마하의 추가 개발에도 영향을 미쳤습니다.

그 결과로 만들어진 마하 3는 1990년에 출시되었고, 큰 관심을 불러 일으켰습니다.소규모 팀이 마하를 구축하여 복잡한 멀티프로세서 시스템을 포함한 여러 플랫폼에 이식했는데, 이는 오래된 스타일의 커널에 심각한 문제를 일으키고 있었습니다.이로 인해 다수의 기업들이 하드웨어 플랫폼 변화를 고려하는 와중에 상업 시장에서 상당한 관심을 갖게 되었습니다.기존 시스템을 마하에서 실행할 수 있도록 포팅할 수 있다면 아래 플랫폼을 변경하는 것이 쉬울 것입니다.

OSF(Open Software Foundation)가 향후 버전의 OSF/1을 마하 2.5에서 호스팅할 것이라고 발표했을 때 마하는 가시성이 크게 향상되었고, 마하 3도 조사 중이었습니다.또한 마하 2.5는 NeXTSTEP 시스템과 다수의 상용 멀티프로세서 벤더를 대상으로 선정되었습니다.마하 3은 마이크로커널을 위해 IBM의 Workplace OS를 포함한 다른 운영 체제 부품을 이식하기 위한 많은 노력과 애플이 클래식 맥 OS의 크로스 플랫폼 버전을 구축하기 위한 여러 노력으로 이어졌습니다.[10]

성능문제

마하는 원래 고전적인 단일 UNIX를 대체하기 위한 것이었고, 이러한 이유로 많은 UNIX와 유사한 아이디어를 포함했습니다.예를 들어, 마하는 UNIX의 파일 시스템에 패턴화된 권한 및 보안 시스템을 사용했습니다.커널은 다른 OS 서버와 소프트웨어에 대한 특권(커널 공간에서 실행)이었기 때문에 오작동하거나 악의적인 프로그램이 시스템에 손상을 입힐 수 있는 명령을 보낼 수 있었고, 이러한 이유로 커널은 모든 메시지의 유효성을 확인했습니다.또한 운영 체제 기능의 대부분은 사용자 공간 프로그램에 위치해야 했기 때문에 커널이 이러한 프로그램에 직접 하드웨어에 액세스할 수 있는 추가적인 권한을 부여할 수 있는 방법이 필요했습니다.

마하의 난해한 기능 중 일부는 이와 같은 IPC 메커니즘을 기반으로 합니다.예를 들어, 마하는 멀티 프로세서 머신을 쉽게 지원할 수 있었습니다.기존의 커널에서는 다른 프로세서에서 실행되는 프로그램이 동시에 커널로 호출될 수 있기 때문에 재진입하거나 중단할 수 있도록 광범위한 작업을 수행해야 합니다.마하 하에서 운영 체제의 비트는 서버에서 격리되며, 서버는 다른 프로그램과 마찬가지로 모든 프로세서에서 실행할 수 있습니다.이론적으로는 마하 커널도 재진입해야 하지만, 실제로는 응답 시간이 너무 빨라 요청을 차례로 대기하고 제공할 수 있기 때문에 문제가 되지 않습니다.마하는 또한 프로그램 간뿐만 아니라 네트워크를 통해서도 메시지를 전달할 수 있는 서버를 포함하고 있었습니다. 이 서버는 1980년대 후반과 1990년대 초반에 집중적으로 발전한 분야였습니다.

안타깝게도, 거의 모든 작업에 IPC를 사용하면 성능에 심각한 영향을 미치는 것으로 나타났습니다.1997년 하드웨어에 대한 벤치마크 결과, 마하 3.0 기반 유닉스 단일 서버 구현 속도가 기본 유닉스보다 약 50% 느렸습니다.[11][12]

수행 문제의 정확한 성격에 대한 연구는 많은 흥미로운 사실들을 밝혀냈습니다.하나는 IPC 자체가 문제가 아니라는 것이었습니다. IPC를 지원하는 데 필요한 메모리 매핑과 관련된 오버헤드가 일부 있었지만, 이로 인해 통화에 필요한 시간이 조금밖에 추가되지 않았습니다.나머지 80%의 시간을 할애한 것은 커널이 메시지에서 실행 중인 추가 작업 때문이었습니다.이 중에서 가장 중요한 것은 포트 권한 검사와 메시지 유효성입니다.486DX-50의 벤치마크에서 표준 UNIX 시스템 호출을 완료하는 데 평균 21μs가 소요된 반면, 마하 IPC와 동등한 작동은 평균 114μs였습니다.이 중 18μs만 하드웨어와 관련이 있었고 나머지는 메시지의 다양한 루틴을 실행하는 마하 커널이었습니다.[13]아무 것도 하지 않는 시스콜이 주어지면, BSD 하에서 전체 왕복은 약 40μs가 필요한 반면, 사용자 공간 마하 시스템에서는 500μs 미만의 시간이 소요됩니다.

마하가 처음 2.x 버전에서 심각하게 사용되었을 때, 성능은 기존의 단일 운영 체제보다 25%[1]나 더 느렸습니다.그러나 이 시스템은 멀티 프로세서 지원과 간편한 휴대성을 제공하기 때문에 이 비용은 특별히 걱정할 만한 것으로 생각되지 않았습니다.많은 사람들이 이것이 예상되고 받아들일 수 있는 지불 비용이라고 생각했습니다.MIPS R3000의 Mach와 Ultrix 간 벤치마크는 일부 워크로드에서 67%에 달하는 성능 히트를 나타냄에 따라 대부분의 운영 체제를 사용자 공간으로 이동하려고 했을 때 오버헤드가 더욱 커졌습니다.[14]

예를 들어, 시스템 시간을 얻는 것은 시스템 시계를 유지하는 사용자 공간 서버에 대한 IPC 호출을 포함합니다.호출자는 먼저 커널에 트랩되어 컨텍스트 스위치와 메모리 매핑을 발생시킵니다.그런 다음 커널은 발신자에게 필요한 액세스 권한이 있으며 메시지가 유효한지 확인합니다.그렇다면 사용자 공간 서버에 통화를 완료하기 위한 다른 컨텍스트 스위치와 메모리 매핑이 있습니다.그런 다음 결과를 반환하기 위해 프로세스를 반복해야 하며, 총 4개의 컨텍스트 스위치와 메모리 매핑, 그리고 2개의 메시지 확인을 추가합니다.이러한 오버헤드는 많은 서버를 통과하는 코드 경로가 종종 존재하는 보다 복잡한 서비스와 빠르게 결합됩니다.

성능 문제의 원인은 이뿐만이 아니었습니다.또 하나는 물리적 메모리가 부족하고 페이징이 발생해야 할 때 메모리를 제대로 처리하려고 하는 문제에 초점을 맞췄습니다.기존의 단일 운영 체제에서 저자들은 커널의 어떤 부분이 어떤 다른 부분이라고 부르는지 직접적인 경험을 했고, 이를 통해 호출기를 미세 조정하여 사용하려던 코드를 페이징 아웃하지 않도록 할 수 있었습니다.마하에서는 커널이 운영체제가 무엇으로 구성되어 있는지 전혀 알지 못했기 때문에 이것은 불가능했습니다.그 대신 단일한 크기의 모든 솔루션을 사용해야 했고, 이로 인해 성능 문제가 가중되었습니다.마하 3는 더 나은 전문화를 위해 사용자 공간 호출기에 의존하여 간단한 호출기를 제공함으로써 이 문제를 해결하고자 했습니다.하지만 이것은 별 효과가 없는 것으로 드러났습니다.실제로는 IPC를 호출하는 데 필요한 값비싼 IPC로 인해 모든 혜택이 사라졌습니다.

다른 성능 문제는 Mach의 멀티프로세서 시스템 지원과 관련이 있었습니다.1980년대 중반부터 1990년대 초반까지 일반 CPU의 성능은 연간 약 60%의 속도로 증가했지만 메모리 액세스 속도는 연간 7%에 불과했습니다.이는 메모리 액세스 비용이 이 기간 동안 엄청나게 증가했음을 의미하며, 마하는 프로그램 간의 메모리 매핑을 기반으로 했기 때문에 "캐시 미스"로 인해 IPC 호출 속도가 느려졌습니다.

잠재적 해결책

IPC 오버헤드는 마하 3 시스템의 주요 문제입니다.그러나 아직 연구가 필요하지만 다중 서버 운영 체제의 개념은 여전히 유망합니다.개발자들은 코드를 서버에서 서버로 호출하지 않는 모듈로 분리하는 데 주의해야 합니다.예를 들어, 대부분의 네트워킹 코드가 단일 서버에 배치되므로 정상적인 네트워킹 작업을 위한 IPC가 최소화됩니다.

대신 대부분의 개발자들은 운영 체제 기능을 제공하는 단일 대형 서버라는 원래의 POE 개념을 고수했습니다.[15]개발을 쉽게 하기 위해 운영 체제 서버를 사용자 공간 또는 커널 공간에서 실행할 수 있도록 했습니다.이를 통해 사용자 공간에서 개발하고 원래 마하 아이디어의 모든 장점을 갖춘 다음 디버그된 서버를 커널 공간으로 이동하여 성능을 향상시킬 수 있었습니다.그 후 여러 운영 체제(co-location)가 개발되었으며, 그 중 Lites, MkLinux, OSF/1, NeXTSTEP/OPENSTEP/macOS 등이 있습니다.코러스 마이크로커널은 이것을 기본 시스템의 기능으로 만들어 내장된 메커니즘을 사용하여 서버를 커널 공간으로 올릴 수 있게 했습니다.

마하 4는 이러한 문제를 해결하기 위해 이번에는 보다 근본적인 업그레이드를 시도했습니다.특히, 프로그램 코드는 일반적으로 쓰기가 불가능한 것으로 나타나 카피 온 라이트로 인한 잠재적인 히트는 드물었습니다.따라서 IPC용 프로그램 간에 메모리를 매핑하지 않고 사용 중인 프로그램 코드를 프로그램의 로컬 공간으로 마이그레이션하는 것이 타당했습니다.이것은 "셔틀"의 개념으로 이어졌고 성능이 향상된 것처럼 보였지만 개발자들은 반사용 가능한 상태로 시스템을 진행했습니다.마하 4는 또한 내장된 공동 위치 프리미티브를 도입하여 커널 자체의 일부로 만들었습니다.

1990년대 중반까지 마이크로커널 시스템에 대한 작업은 대체로 정체되어 있었지만, 시장은 일반적으로 1990년대까지 모든 현대 운영 체제가 마이크로커널 기반이 될 것이라고 믿었습니다.마하 커널이 널리 사용되는 주요한 용도는 애플의 macOS와 형제 iOS로, 이들은 OSF/1에서도 사용되는 "XNU"[16]라고 불리는 많이 변형된 하이브리드 오픈 소프트웨어 기반 마하 커널(OSFMK 7.3) 위에서 작동합니다.[10]XNU에서 파일 시스템, 네트워킹 스택, 프로세스 및 메모리 관리 기능은 커널에 구현되며, 파일 시스템, 네트워킹 및 일부 프로세스 및 메모리 관리 기능은 메시지 전달이 아닌 일반 시스템 호출을 통해 사용자 모드에서 호출됩니다.[17][18] XNU의 마하 메시지는 사용자 모드 프로 간의 통신에 사용됩니다.사용자 모드 코드에서 커널로, 커널에서 사용자 모드 서버로 일부 요청을 하는 경우.

2세대 마이크로커넬

추가 분석을 통해 IPC 성능 문제가 보이는 것만큼 명확하지 않다는 것이 입증되었습니다.동일한 시스템에서 작동하는 BSD에서는[3] 단일 측면에서 20μs, 마하에서는 114μs의 시간이 걸렸다는 것을 기억하십시오.[2]114개 중 11개는 BSD와 동일하게 컨텍스트 스위치에 의한 것이었습니다.[12]MMU는 사용자 공간과 커널 공간 사이에 메시지를 매핑하기 위해 추가로 18개를 사용했습니다.[3]이는 기존의 시콜보다 긴 29μs에 불과하지만 많은 양은 아닙니다.

실제 문제의 대부분인 나머지는 커널이 포트 액세스 권한을 위해 메시지를 확인하는 등의 작업을 수행했기 때문입니다.[6]이것이 중요한 보안 문제인 것처럼 보이지만, 사실 UNIX와 같은 시스템에서만 의미가 있습니다.예를 들어, 휴대폰이나 로봇을 구동하는 단일 사용자 운영 체제에는 이러한 기능이 필요하지 않을 수 있으며, 바로 마하의 선택-선택 운영 체제가 가장 가치 있는 시스템입니다.마찬가지로 마하는 운영 체제에 의해 메모리가 이동되었을 때 문제를 일으켰는데, 이는 시스템에 둘 이상의 주소 공간이 있을 경우에만 실제로 의미가 있는 또 다른 작업입니다.DOS와 초기 Mac OS에는 모든 프로그램이 공유하는 하나의 큰 주소 공간이 있기 때문에 이러한 시스템에서는 매핑을 통해 어떠한 이점도 얻을 수 없었습니다.

이러한 인식은 일련의 2세대 마이크로커넬로 이어졌으며, 이는 시스템의 복잡성을 더욱 감소시키고 사용자 공간에 거의 모든 기능을 배치했습니다.예를 들어, L4 커널(버전 2)은 단지 7개의 시스템 호출을 포함하고 12k의 메모리를 사용하는 반면,[3] 마하 3은 약 140개의 기능을 포함하고 약 330k의 메모리를 사용합니다.[3]486DX-50의 L4에서 IPC를 호출하는 데 걸리는 시간은 5μs로,[18] 동일한 시스템의 UNIX syscall보다 빠르며 마하보다 20배 이상 빠릅니다.물론 이는 L4가 권한이나 보안을 처리하지 않는다는 사실을 무시하는 것이지만, 사용자 공간 프로그램에 이를 맡기면 필요한 만큼의 오버헤드를 선택할 수 있습니다.

L4의 잠재적인 성능 향상은 사용자 공간 애플리케이션이 커널이 이전에 지원했던 많은 기능을 제공해야 하는 경우가 많다는 사실에 의해 완화됩니다.엔드 투 엔드 성능을 테스트하기 위해, 동일 위치 모드의 MkLinux와 사용자 공간에서 실행되는 L4 포트를 비교했습니다.L4는 마하의 29%[12]에 비해 [12]오버헤드가 약 5%–10% 추가되었습니다.

마하 기반 소프트웨어

다음은 마하에서 파생된 운영 체제 커널과 마하에서 파생된 커널을 가진 운영 체제 목록입니다.

참고 항목

참고문헌

  1. ^ a b "Mach: Define Mach at Dictionary.com". Dictionary.com. Retrieved 12 December 2016.
  2. ^ a b c "CMU CS Project Mach Home Page".
  3. ^ a b c d e McKusick, Marshall Kirk; Bostic, Keith; Karels, Michael J.; Quarterman, John S. (Apr 30, 1996). The Design and Implementation of the 4.4 BSD Operating System. Addison-Wesley. p. 123. ISBN 978-0-7686-8494-0.
  4. ^ a b Al Saracevic (March 27, 2006). "Adios Avie". The Technology Chronicles. Retrieved 23 January 2010.
  5. ^ "Dario A. Giuse, PhD, MS, FACMI". Archived from the original on 23 August 2020.
  6. ^ a b Singh, Amit (2006-07-28). "A Technical History of Apple's Operating Systems". osxbook.com. Archived from the original on 27 August 2019. Retrieved 18 March 2011.
  7. ^ Tevanian, Avadis; Rashid, Richard F.; Golub, David B.; Black, David L.; Cooper, Eric; Young, Michael W. (1987). Mach Threads and the Unix Kernel: The Battle for Control. USENIX Summer Conference. USENIX. pp. 185–197. CiteSeerX 10.1.1.41.3458.
  8. ^ Accetta, Mike; Baron, Robert; Bolosky, William; Golub, David; Rashid, Richard; Tevanian, Avadis; Young, Michael (1986). Mach: A New Kernel Foundation for UNIX Development (PDF). USENIX Summer Conference. USENIX.
  9. ^ (부록 B, 운영체제 개념)
  10. ^ a b Douglas M. Wells (1994). A Trusted, Scalable, Real-Time Operating System Environment (PDF). 1994 IEEE Dual-Use Technologies and Applications Conference. S2CID 5205380. Archived from the original (PDF) on 2017-08-22.
  11. ^ M. Condict; D. Bolinger; E. McManus; D. Mitchell; S. Lewontin (April 1994). "Microkernel modularity with integrated kernel performance". Archived from the original on 2017-06-19. Retrieved 2019-02-19.
  12. ^ a b c d Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian; Wolter, Jean (October 1997). The performance of μ-kernel-based systems. 16th ACM symposium on Operating systems principles (SOSP'97). Vol. 31. Saint-Malo, France. p. 67. doi:10.1145/269005.266660. ISBN 0-89791-916-5.
  13. ^ Jochen Liedtke (1993). "Improving IPC by Kernel Design". Proceedings of the 14th ACM Symposium on Operating System Principles (SOSP). CiteSeerX 10.1.1.55.9939. doi:10.1145/168619.168633. ISBN 978-0-89791-632-5.
  14. ^ Chen, J B; Bershad, B N (1993). "The impact of operating system structure on memory system performance". ACM SIGOPS Operating Systems Review. 27 (5): 133. CiteSeerX 10.1.1.52.4651. doi:10.1145/173668.168629.
  15. ^ Mary Thompson (14 April 1994). "A Brief Description of the POE server".
  16. ^ Jim Magee. WWDC 2000 Session 106 - Mac OS X: Kernel. 14 minutes in. Archived from the original on 2021-12-11.
  17. ^ "Kernel Architecture Overview". Kernel Programming Guide. Apple Inc. August 8, 2013. Retrieved March 3, 2015.
  18. ^ a b "Boundary Crossings". Kernel Programming Guide. Apple Inc. August 8, 2013. Retrieved March 3, 2015.
  19. ^ Apple Inc. (February 26, 2013), Mach Overview

외부 링크