QNX的體系架構概述

Dan Hildebrand

Quantum Software Systems Ltd. 量子軟體系統有限公司

175 Terrence Matthews

Kanata, Ontario K2M 1W8

Canada

[phone]

[email protected]

摘要

本文從架構視角上來展現QNX作業系統。QNX作業系統為應用程式提供了完整的面向網絡、多處理器和分布式的實時環境，幾乎可以實作底層硬體在驅動級别上的全部性能特性。用于傳遞這個操作環境的OS體系結構，是由一系列可選程序圍繞着實時微核心，這些程序提供了POSIX和UNIX相容的系統服務。通過對運作時中包含或排除各種資料總管，可以将QNX縮減為基于ROM的嵌入式系統，或者擴充到包含數百個處理器——通過各種LAN技術緊密或松散地連接配接在一起。與POSIX标準1003.1、草案标準1003.2（Shell腳本和實用工具）和草案标準1003.4（實時）的相容性會在整個分布式環境中被透明地維護。

*本論文發表于西雅圖1992年4月，關于微核心和其它核心架構的USENIX研讨會。ISBN 1-880446-42-1。QNX是注冊商标，FLEET是量子軟體系統有限公司的商标。

架構：曆史和現狀

自從它在1982年被建立以來，QNX體系結構從根本上一直類似于它目前的形式——一個非常小的微核心（當時大約為10KB），由一組協作的程序所圍繞着，來提供更進階别的作業系統服務。到目前為止，QNX已經在近20萬個系統中使用，主要應用于要求實時性能、開發靈活性和網絡靈活性的應用程式中。大量的安裝已經證明，微核心技術在商業上是可行的，并适合于關鍵任務應用，例如過程控制、醫療儀器和金融交易處理等。這些應用程式的性能需求一直是QNX從1.00版本到3.15版本演進的重要驅動力。

在1989年開始開發的相容POSIX的QNX (4.0)版本，以最大化繼承前一代産品的性能和靈活性為目标。這個新版本釋出于1991年。本文将詳細介紹新架構的特點，并讨論其優勢和限制，以及未來發展的目标。

真正的微核心

QNX微核心實作了四個服務：程序間通信、低級網絡通信、程序排程和中斷排程。有14個與這些服務相關的核心調用。總體而言，這些功能占據大約7KB的代碼，并提供實時執行的功能和性能（參見附錄A）。考慮到核心的大小很小，一個提供了合理的片上緩存的處理器，就可以為大量使用微核心服務的應用程式提供優良的性能，因為微核心和系統中斷處理程式通常可以适應CPU的8KB片上緩存。

圖1： QNX微核心

微核心以阻塞版本的Send()、Receive()和Reply()來提供的消息傳遞功能。也即是說，一個程序使用Send()發送到另一個程序時将被阻塞，直到目标程序執行Receive()、處理消息并執行Reply()。如果一個程序執行Receive()後沒有消息被傳遞，它将被阻塞直到另一個程序執行Send()。由于這些原語不經過隊列，而直接從程序複制到程序，其消息傳遞的性能接近底層硬體的記憶體帶寬。所有的系統服務都建立在這些消息傳遞原語之上。使用這些低級服務，可以很容易被實作這些IPC原語的變體（例如消息隊列）的服務。

相對于單核心（Monolithic-kernel）中實作的這些服務的性能，這些替代的IPC服務的性能與之相當，而且常常更加優越 (見附錄B)。

圖2：典型的發送-接收-回傳事務中的涉及的狀态

程序可以請求以優先級順序（而不是按時間先後順序）來處理消息，并且以因等待服務而阻塞的程序中的最高優先級來執行。這種消息驅動的優先級機制，巧妙地避免了在固定優先級消息傳遞系統中，可能導緻的優先級反轉問題。服務程序被強制以它們所服務的程序的優先級來執行，并且當高優先級程序阻塞在繁忙的服務上時，服務程序的優先級還會自動的得到适當的提升。是以，低優先級的程序不能通過調用一個更高優先級的服務程序上的服務來搶占更高優先級的程序。

消息傳遞原語支援多部件（multi-part）的消息傳遞，這樣從一個程序傳遞到另一個程序的消息不需要占用記憶體中的單個連續區域。與之相反，發送和接收程序都可以指定一個MX表（MX table），它訓示了在記憶體中發送和接收消息片段的位置。這使得消息頭塊與資料塊可以分隔開，而不需要為了建立一個連續的消息，而執行消耗性能的資料複制。此外，如果底層資料結構是一個環形緩沖區，那麼一種三部件（three-part）的消息将允許在環形緩沖區内的頭和兩個不相交的區間作為單一的原子消息來發送。發送方和接收方各自應用到消息的MX映射（MX mapping）不必是相同的。

圖3：多部件消息可以通過使用MX控制結構來指定。微核心會将這些資料組裝到單一資料流中。

低級網絡通信被直接設計到了微核心中，并由被稱為網絡管理器的可選程序來提供（本文稍後将介紹）。當存在網絡管理器時，它會直接連接配接到微核心，并為微核心提供将消息複制到LAN上的其它微核心所需的功能。通過在系統中基礎層面上提供的網絡服務，任何在作業系統中的更高架構層上提供的服務，都可以透明地被任何程序、在網絡上的任何地方通路。從架構上講，這個實作非常精簡，盡可能的提供了高效的接口。

QNX提供的程序排程原語符合POSIX 1003.4（實時）草案規範。QNX提供了完全搶占式、輪詢的優先級的上下文切換、FIFO和自适應排程。當POSIX 1003.4标準走出草案狀态時，微核心和系統程序将被演化以進行比對。

資料總管和路徑名空間管理

對于要提供POSIX标準和UNIX約定指定的功能的微核心，可以添加被稱為資料總管的可選程序。一個沒有檔案系統或裝置I/O系統的最小系統，可以建構為微核心、程序管理器和一組應用程式程序。

第一個，也是唯一一個強制性的資料總管是程序管理器（Proc）。Proc提供了諸如程序建立、程序會計（process accounting）、記憶體管理、程序環境繼承（包括本地和網絡遠端程序）和路徑名空間管理的服務。第一級路徑名管理是由Proc完成的，因為不同于單核心系統中始終存在檔案系統，在QNX下檔案系統是可選的。無磁盤或基于ROM的系統可能不需要檔案系統，是以也不必強制使用。

在資料總管開始執行之前，Proc“擁有”整個路徑名空間（根和根下面的一切）。如果沒有任何資料總管提供服務，這本質上就是一個空檔案系統。Proc允許資料總管通過一個标準的API來使用名稱空間中，它們想要管理的部分（一個“授權領域”）。然後，Proc負責維護一個字首樹來跟蹤擁有路徑名空間各個部分的程序。

當Fsys（檔案系統管理器）和Dev（裝置管理器）正在運作時，字首樹将如下所示：

/                    基于磁盤的檔案系統 (Fsys)

/dev                字元裝置系統 (Dev)

/dev/hd0        原始磁盤卷 (Fsys)

/dev/null        空裝置 (Dev)

當一個程序打開一個檔案時，open()庫例程首先将檔案名發送到Proc，在這裡将路徑名應用于字首樹，以便将open()指向适當的資料總管。在授權領域重疊的情況下，對路徑名的最長比對将獲勝。例如，如果 /dev/tty0 被打開，最長的比對将發生在 /dev 上，使得open指向 /dev。路徑名 /usr/fred 将比對到 / ，使得打開到Fsys。

網絡中的每台計算機上的程序管理器，都會維護它自己的字首樹，并可能對在每個節點上的程序，呈現出相同或不同的視圖的網絡範圍路徑名空間。以 / 開頭的路徑名會應用到該節點上的字首樹。應用程式也可以使用網絡惟一名稱，用來指定網絡範圍路徑名空間中資源的絕對位置。通過使用字首别名，可以将名稱空間的一部分映射到其他網絡節點的資料總管上。例如，從LAN啟動的無盤工作站，想要将其檔案系統挂載在另一個節點上，進而可以将其檔案系統的根别名到遠端的Fsys程序。

有了這個别名，對 /dev 的open()調用将仍被映射到本地的Dev程序以控制本地的裝置，但所有對檔案的open()調用則會導緻打開消息在先前指定的遠端節點上的字首映射表上進行解析（通常将對檔案的打開操作，引導到那個結點上的Fsys程序）。是以，網絡上任何地方的程序都可以在單個目錄樹上通路所有的網絡檔案系統資源，連接配接到一個公共根目錄。或者，通過使用網絡絕對路徑名，網絡路徑名空間也可以被操作為單個根檔案系統的集合。

通過在正常的檔案命名空間中實作各個域的權限，使得整個作業系統的各個功能部分，可以以運作時可選（runtime-optional）的方式實作。由于資料總管位于核心空間之外，并且與使用者程序沒有本質差別，是以可以在運作時動态地添加或删除它們，而不需要将核心重新連結以便包含不同級别的功能。根據應用程式的需要，這種分級的靈活性使得作業系統可以輕松地的放大或縮小。

盡管将資料總管提供的服務放置在核心之外，但最初看起來效率很低，但是在附錄B中給出的性能結果表明，微核心的上下文切換和IPC性能足以比對硬體的原始性能。

這個名稱空間的網絡透明性允許遠端執行程序，在邏輯上等同于在本地處理器上的執行。單獨管理的路徑名空間無縫地融合，并且在名稱空間的行為方式上沒有“驚喜”。在繼承了整個的父程序環境，包括打開的檔案描述符、環境變量和目前的工作目錄之後，盡管處于網絡分布式運作時的上下文，處理器間通信和檔案I/O都是按照POSIX 1003.1規範操作的。

Fsys——檔案系統管理器

Fsys是資料總管，它為QNX環境提供了一個符合POSIX的檔案系統。它實作了一個磁盤結構，該結構使用了位圖來配置設定空閑空間，并使用了一種擴充的連結清單的方法來組織磁盤上的資料。這種方法允許系統在應用程式級上達到接近硬體原始性能的磁盤吞吐量（見附錄B）。Fsys将對檔案系統的完整性至關重要的資料結構同步寫入磁盤，進而使得磁盤系統在意外斷電的情況後還能夠順利地運作。在磁盤資料結構中嵌入的特殊标記，使得檔案系統在發生災難性故障時很容易被重建。

Fsys的多線程體系結構允許它并行處理多個請求，這樣當其他線程被阻塞時，就會觸發虛拟硬碟（Ramdisk）和緩存I/O，等待發生實體I/O。這種并行性也延伸到了驅動程式中——如果一個裝置支援多個待處理的I/O請求，那麼驅動程式可以以任何合适的順序為這些請求來服務。

盡管對消息傳遞類作業系統的初步研究表明，這個檔案系統可能需要比單核心檔案系統複制更多的資料，但實際情況是不需要額外的複制。MX多部件消息原語允許Fsys将應用程式調用read()和write()時指定的連續緩沖區，映射到Fsys中非連續緩存塊。對于讀取磁盤，磁盤驅動器從磁盤讀取到多個非連續的由LRU算法配置設定的緩存塊。然後，Fsys在核心中調用MX工具以原子方式收集并将分散的塊，複制到應用程式指定的連續讀取緩沖區中。是以，即使檔案系統存在于一個消息傳遞類網絡透明的環境中，它也顯示了與在單核心中實作的檔案系統相同數量的資料複制。

Fsys程序可以從無磁盤連接配接網絡的機器上以指令行方式啟動，然後将裝置驅動程式動态地附加到Fsys上。如果不再需要Fsys時，可以從記憶體中删除Fsys及其驅動程式。

Dev——裝置管理器

裝置管理器 (Dev) 提供了與POSIX相容的裝置控制，并提供了一些适合于實時通信的擴充。類似于Fsys，Dev也可以被動态啟動，并附加上其裝置驅動程式，然後在不再需要時從記憶體中删除。

由于微核心提供了較低的中斷延遲，開發人員可以在一般的硬體上使用非智能UART裝置來處理最高至115 K的波特率。通過添加智能通信闆，可以配置高帶寬、多線通信伺服器。

MX消息傳遞原語的使用，允許Dev以Receive()收到應用程式對裝置執行的write()操作，并将其直接寫入由中斷處理程式所管理的環形緩沖區中。通過适當地定義MX表，可以将接收到的資料直接寫入由Dev管理的循環緩沖區。由于寫入一個循環緩沖區可能要求資料被映射到實體上分離（但邏輯上連續）的記憶體區域，一個有三個條目的MX表可以描述環形緩沖區的頭和其上兩個實體上不相交的部分。對于read()的情況，來自裝置的資料流直接從驅動程式進入環形緩沖區，并從環形緩沖區進入應用程式的read()緩沖區，而不需要進行備援的複制來建構連續的消息。

裝置驅動支援

與其堅持裝置驅動程式的中斷處理程式隻能存在于核心空間中，QNX提供了一個系統調用，允許使用者程序将具有足夠特權使用者程序中的處理程式，連接配接到核心中的特定中斷向量。然後核心可以調用所連接配接的處理程式來響應實體中斷。處理程式通過存在于使用者程序中，可以完全通路程序的位址空間以便于響應中斷。一旦處理程式開始運作，它可以喚醒與其共享代碼的程序，也可以簡單地傳回核心。Dev的裝置驅動程式利用這種行為，使用單獨的中斷在Dev管理的緩沖區中累積字元，隻有在預先定義的“重要事件”（如終端字元計數、行結束條件或逾時）發生時才喚醒Dev。

以這種方式在核心外部存在的中斷處理程式的情況下，使用者可以從正在運作的系統中，動态地添加和删除中斷處理程式（以及包含它們的裝置驅動程式）。由核心完成的第一級中斷處理，還處理嵌套和共享的中斷，而不會将依賴硬體的細節和複雜性，強加給使用者編寫的中斷處理程式。微核心對外部中斷處理程式的支援，對于資料總管匹敵單核心内的資源管理所能提供的性能水準是至關重要的。

容易擴充

裝置驅動程式存在于使用者程序中的一個基本優勢是，開發一個作業系統的擴充，在功能上與開發使用者級程序沒有差別。事實上，在量子公司内部使用的開發方法中，對實驗性質的資料總管的執行，是在全屏的、源代碼級調試器的控制下的，進而能夠完成對作業系統的服務如一個新的 Fsys 程序的調試，而不必訴諸低功能的工具，如核心調試器通常用于在單核心作業系統中調試核心連結的（kernel-linked）擴充。由于可以随意啟動和删除資料總管和裝置驅動程式，重新連結核心并重新開機，以測試新核心的繁瑣過程變得完全沒有必要。

作為說明QNX系統多麼容易擴充的例子，一個在[Pike 90]中描述的與 /proc 資料總管類似的服務，由應用程式級的程式員（不是核心架構師！），經過僅僅幾個小時的努力，以不到200行容易了解的C源代碼實作了。實際上，/proc資料總管打包了一種系統資源（系統中活動程序的清單），然後将其以檔案和目錄的形式提供給系統，可以在 /proc 路徑名空間中進行操作。

作為一個更複雜的示例，一個類似于[Presotto 91]所描述的用戶端網絡檔案系統緩存管理器的實作大約花費了一周的時間。該緩存将最近通路的檔案塊的副本儲存在用戶端，供通路網絡遠端Fsys的節點使用。在open()調用時，緩存管理器會驗證遠端檔案沒有被更改（這會使本地緩存的資料無效），并提供本地緩存的資料以提供性能增強。通過為這個用戶端緩存提供一個本地磁盤檔案以“流入（spill）”到其中，一個通過緩慢的串行鍊路進行網絡連接配接的系統，仍然可以提供合理的網絡遠端檔案系統性能。該伺服器的實作僅1000行源代碼，再次的，使用标準系統庫的應用程式級程式員完全可以了解它。

最後，可以将客戶檔案系統實作為一個資料總管，它使用 Fsys 的原始磁盤塊I/O服務在根檔案系統中以子樹的形式顯示客戶檔案系統。一個例子是 Dosfsys，一個PC-DOS檔案系統。Dosfsys采用 /dos 路徑名作為其授權域，然後向系統呈現 /dos/a、/dos/b等一系列目錄。這些目錄映射到了相應的PC-DOS媒體，Dosfsys程序會操作這些卷上，輸入到Dosfsys的I/O請求所訓示的原始塊。能夠映射到底層檔案系統的檔案操作是被支援的，而其他操作（如link()），在嘗試時則傳回适當的錯誤狀态。

網絡服務——FLEETTM網絡技術

Fault-tolerant        容錯性

Load-balancing    負載均衡

Efficient                 效率高

Extensible             可擴充

Transparent          透明性

如前所述，網絡管理器（Net）是直接連接配接到微核心中。當微核心被調用來将一個消息從本地程序傳遞到另一個節點上的程序時，它會通過這個私有接口将指向這個消息的指針排隊到Net中。類似地，Net可以接收來自其它微核心的消息，并将這些消息發送給本地微核心。本質上，網絡上的網絡管理器将許多遠端的微核心整合到一個微核心中。由于所有系統服務（包括程序建立、調試、檔案和裝置I/O）都是通過微核心傳遞的消息來完成的，是以結果是一個計算機網絡的行為類似于一台計算機。在作業系統的更高架構層級上提供的任何服務都可以被網絡上的所有程序透明地通路。這與TCP/IP服務套件形成了鮮明的對比，後者隻提供非常明确的服務集——通常是終端會話和檔案通路。相比之下，這種連接配接的微核心架構允許以下指令：

ls /usr/danh | grep abc | wc

使每個程序在網絡上的不同處理器上運作，而Proc提供網絡繼承的檔案描述符使得管道可以通過網絡連接配接和轉發資料。這種環境的透明性也促進了分布式應用程式的實作。例如，從傳統的非分布式版make開始，一個網絡分布式團隊版make實用程式的開發僅用了一周的時間就完成了。

就像Fsys和Dev可以從指令行啟動和停止一樣，這兩個驅動程式都有一組驅動程式族，Net也有一組驅動程式族，支援多個網絡驅動程式到Net的連接配接。如果Net發現不止一個網絡驅動程式提供到相同節點的連接配接，它将在驅動程式之間負載平衡流量。負載均衡使用基于媒體傳輸速率和隊列深度的算法。也可以根據提供的指令行選項，手動控制網絡流量。

通過在網絡節點之間添加額外的網絡連結，節點之間使用多個網絡路徑可以提供更好的吞吐量和容錯能力。不需要在應用程式級進行更改就能利用這種容錯性，因為這種支援是在網絡管理器内部本地存在的。

圖4：多個實體網絡通過邏輯網絡愉快地共存

如果主LAN發生故障，廉價的串行鍊路可以用作備用（fall-back）網絡鍊路。通過以高波特率（Dev可以達到115 K波特率）運作串行鍊路、進行資料壓縮和啟用用戶端檔案系統緩存，串行網絡的性能也可以非常快。

此功能還可用于解決LAN擁塞問題，也即兩個檔案伺服器在LAN上做大量點到點傳輸。使用FLEET方法，可以添加一個私有網絡連結來連接配接這兩個伺服器，進而将點對點流量從主LAN轉移到私有連結上。如果兩台伺服器在實體上是相鄰的，那麼非傳統的LAN技術（如點到點SCSI或總線到總線DMA）就成為可行的選擇。此方法可用于實作[Presotto 91]中描述的CPU/檔案伺服器組。

FLEET方法還允許使用系統底闆總線建構多處理器系統，方法是建構一個處理器闆，該處理器闆将底闆總線用作VLAN（Very Local Area Network非常區域網路）。每個處理器闆将運作一個由微核心、Proc、Net和Net.vlan驅動程式組成的QNX OS。其中一個處理器運作的Net，同時包含Net.vlan驅動程式和Net.ethernet驅動程式，來通路外部以太網LAN。通過向這些處理器添加額外的硬體，以及适當的Dev或Fsys程序，它們就變成了分布式I/O處理器。目前，使用VLAN的微通道總線（Microchannel bus）對該體系結構的測試實作正在與Aox公司共同開發中。微通道突發模式和多主（multimaster）總線仲裁與VLAN一樣具有良好的性能。實際上，以太網上的每個節點都可以通過額外的處理器在機箱中包含VLAN。這使得通常在每個以太網節點上運作的一組程序可以在該節點内的一組處理器上重新分發和運作。由[Tanenbaum 89]描述的計算伺服器可以很容易地用這種硬體實作。

對于嵌入式應用，最小QNX系統可以放入少于100K的ROM（微核心、Proc和一些應用程式）中。通過添加Net程序和Net驅動程式（大約35K），嵌入式系統可以連接配接到更大的網絡，成為更大的LAN的無縫擴充。這将允許嵌入式系統通路資料庫、圖形使用者界面、LAN網關和其他服務。盡管嵌入式系統的功能有限，但是連接配接到LAN的網絡為在嵌入式系統上運作的程序提供了對整個LAN上的資源的通路。嵌入式系統也可以從LAN引導，進一步減少ROM的需求。由于系統調試服務是通過運作着被調試程式的結點上的Proc程序的标準消息實作的，是以從LAN上的任何其他結點，都可以調試嵌入式系統上的應用程式。

為了承載标準傳輸協定，可以使用Net和網絡驅動程式提供的與克拉克森相容的（Clarkson-compatible）原始資料包傳遞服務。通過以這種方式實作的協定棧，同一實體LAN上的非QNX機器可以通過協定棧與之進行通信，通路多處理器QNX LAN的服務。在外界（如TCP/IP）看來，QNX環境是一個單一的多處理器機器。

目前，FLEET不支援網絡橋接。這要求對未連接配接到公共網絡的節點之間的通信，将需要使用中間代理程序将消息從LAN傳遞到LAN。目前正在研究如何定義一個路由程序，該程序作為Net的一個附件運作，以執行此功能。

可維護性

維護單核心作業系統的一個基本問題是，所有核心代碼都在一個公共的共享位址空間中運作。核心的一部分可能會破壞另一部分的資料空間的危險是非常真實的，在每次将新驅動程式連結到核心時都必須加以考慮。QNX所采用的方法是顯式地定義組成OS的元件之間的接口，這樣每個資料總管就像使用者程序一樣，在自己的記憶體保護空間中運作，OS子產品之間的所有通信都是通過标準的系統IPC服務進行的。是以，由一個資料總管引入的錯誤将被限制在該子系統，而不會損壞系統中其他不相關的資料總管。

鑒于新的資料總管和裝置驅動程式，可以使用與使用者程序相同的工具進行調試和分析，對系統的開發至少可以像應用程式開發一樣有很好的訓示。這一點非常重要，因為它給與了更大的自由來試驗用新方法實作OS子系統，而不是付出巨大的努力用有限的工具來調試核心。

該體系結構還展示了其相對簡單和易于實作的特性，對現有代碼的維護是可管理的，并且添加新特性的任務是具有合理範圍的。下表給出了組成QNX系統的各個子產品的源代碼行數和代碼大小（本文中的所有源代碼行數都是通過計算C源檔案中的分号生成的）。

代碼行數	代碼大小
Microkernel	605	7KB
Proc	3924	52KB
Fsys	4457	57KB
Fsys.ahascsi	596	11KB
Dev	2204	23KB
Dev.con	1885	19KB
Net	1142	18KB
Net.ether	1117	17KB
15930行	204KB

盡管這兩個系統的設計目标有些不同，但是源代碼行數與[Pike 90]相比還是很不錯的。

未來的發展方向

現在QNX已經與UNIX源代碼相容，二進制相容性的開發正在進行中。源代碼和二進制相容性（ABI）的結合，将允許現有UNIX應用程式駐留在QNX運作時平台上，并受益于網絡透明的分布式處理和增強的系統性能。

商業上成功的對稱共享記憶體多處理器機器的出現，也提出了QNX微核心對多處理器支援問題。考慮到微核心的大小小于7K，多處理器支援的複雜性可以限制在系統中定義良好的部分，并有着健壯的實作。由于提供其餘作業系統服務的資料總管程序是多線程獨立的程序，它們将繼承微核心提供的多程序支援，而無需修改，作業系統的各個元件将實作真正的并發。

性能

QNX必須滿足的一個必要挑戰是來自主要關注實時應用程式的客戶群的性能需求。盡管優雅的作業系統架構是一件令人愉快的工作，但“學術優雅”并不一定會創造一個商業上成功的作業系統——它還必須提供比傳統的單核心作業系統更好的性能。目前許多微核心作業系統的設計目标是嘗試比對單核心系統的性能[Guillemont 91]。考慮到目前的單核心系統，如UNIX SVR4，不能提供硬體的全部性能（附錄B），僅比對這種性能級别将不能為作業系統技術的使用者，提供使用基于微核心的系統的顯著優勢。就像RISC處理器一樣，在一項新技術能夠提供明顯的性能優勢之前，它對最終使用者來說隻是一個架構細節，而不是影響購買決策的因素。

為了使QNX将硬體的全部性能傳遞到應用程式級别（并超過單核心作業系統的性能），開發了許多體系結構上的創新。對于這些增強的必要前提是不損害實時系統性能。盡管增加消息傳遞模型的通用性，在最初的研究中可能表明它比單核心有更多的開銷，但是有許多架構思想可以糾正這種誤解。對整個系統性能有重要貢獻的兩個概念，是直接在資料總管中支援中斷處理程式，以及多部件消息傳遞原語。

附錄B包含執行類似操作的戴爾UNIX SVR4 v2.1實作和QNX 4.1實作的性能結果。選擇戴爾UNIX是因為其SVR4産品，移植到Intel 80x86體系結構的良好性能。在第一部分中，我們比較了一個典型的UNIX核心調用（umask）的時間，但是在QNX下，umask()的實作實際上是作為一個消息發給Proc的。umask()的QNX系統調用速率大約是UNIX的三分之一，因為這些調用表示QNX和UNIX的執行順序不同。執行序列如下:

1) 測試程式在核心中調用Send()

2) 核心排程Proc運作

3) 上下文切換到Proc

4) Proc從被阻塞的Receive()調用傳回

5) Proc處理請求

6) Proc調用核心中的Reply()

7) 核心安排運作測試程式

8) 測試程式從Send()核心調用傳回

實際上，QNX做了兩個核心調用、兩個消息傳遞、兩次執行排程代碼，并在UNIX系統執行三個核心調用所需的時間内執行兩個上下文切換。在此過程中，可以在兩個時間點排程其他程序，而不僅僅是在系統定時器間隔上排程。一個明顯的優化可能是向微核心添加更多的核心調用。但是，請注意，這些操作通常不是系統級性能的瓶頸。這些調用作為消息保留給Proc的另一個優點是它們是網絡透明的，可以從網絡上的任何處理器調用。

Yield()調用是在QNX下的一個真正的核心調用，附錄B中的結果顯示核心調用速率是UNIX核心的三倍多。雖然在微核心中實作本報告中測量的其他調用，有着更快的核心調用次數，但是由于這些調用不是系統的性能瓶頸，是以沒有迫切的需要去擴充核心以适應它們。此外，微核心的複雜性越大，對核心的調用就會變得越慢，直到微核心成長為一個單核心，這也意味着所有的限制。

在系統性能級别上，對于IPC、管道I/O和磁盤I/O，我們看到QNX的性能明顯優于UNIX系統。事實上，QNX系統能夠向應用程式提供幾乎全部的原始裝置吞吐量，而SVR4系統則相去甚遠。對于磁盤I/O, QNX比SVR4快得多。随着速度更快的外圍裝置的出現，為了能夠傳遞硬體的全部性能給一類應用程式，UNIX的核心開銷将可能無法适應，除非對處理器性能進行更大的投資。在網絡的情況下，QNX Net程序及其驅動程式将幾乎整個電纜帶寬傳遞給應用程式，即使隻使用性能一般的機器。

結論

通過在實作和分析QNX微核心體系結構所獲得的經驗表明，微核心系統在為應用程式提供相容API的同時，可以比單核心系統表現得更好，并提供更強大的功能。現有的應用程式源代碼繼續保持不變，而對作業系統的擴充的開發變得容易得多。作業系統平台的靈活性也為實作更大的多樣性和更容易對作業系統特性做替代試驗鋪平了道路。正如RISC處理器架構的創新，在計算機硬體中産生了一系列新的性能能力一樣，微核心作業系統架構将在作業系統技術中産生新的性能和功能标準的複興。

參考文獻

[Guillemont 91] M. Guillemont, J. Lipkis, D. Orr, and M. Rozier. A Second-Generation Micro-Kernel Based UNIX: Lessons in Performance and Compatibility. Proceedings of the Usenix Winter’91 Conference, Dallas, January 21-25, 1991, pp. 13-22

[Pike 90] Rob Pike, Dave Presotto, Ken Thompson, and Howard Trickey. Plan 9 from Bell Labs. Proceedings of the Summer 1990 UKUUG Conference, London, July, 1990, pp. 1-9

[Presotto 91] Dave Presotto, Rob Pike, Ken Thompson, and Howard Trickey. Plan 9, A Distributed System. Proceedings of the Spring 1991 EurOpen Conference, Tromso, May, 1991, pp. 43-50

[Tanenbaum 89] Andrew Tanenbaum, Rob van Renesse, and Hans van Staveren. A Retrospective and Evaluation of the Amoeba Distributed Operating System. Technical Report, Vrije University, Amsterdam, October, 1989, pp. 27

附錄A

Til中斷延遲

Tint中斷處理時間

Tiret中斷結束時間

中斷處理簡單的結束。時間是基于保護模式下的20MHz 386處理器測量的。

Til中斷延遲

Tint中斷處理時間

Tsl排程延遲

中斷處理結束并觸發代理。時間是基于保護模式下的20MHz 386處理器測量的。

中斷和程序延遲

處理器	典型中斷延遲 （Til）	中斷結束時間 （Tiret）	排程延遲 （Tsl）	上下文切換
33 MHz 486	6 微秒	5微秒	14微秒	17微秒
25 MHz 486	8 微秒	7微秒	18微秒	22微秒
33 MHz 386	11 微秒	10微秒	27微秒	33微秒
20 MHz 386	19 微秒	17微秒	45微秒	55微秒
16 MHz 386SX	32 微秒	29微秒	77微秒	94微秒
8 MHz 286	65 微秒	59微秒	163微秒	188微秒

附錄B

QNX4.1和SVR4 UNIX的系統性能參數對比

硬體環境：

處理器：	Intel 80486 33MHz，ISA總線
緩存：	片上8KB，片外0KB
記憶體：	16MB
硬碟：	1.2GB Micropolis SCSI硬碟
控制器：	Adaptec 1542B

軟體環境：

QNX基準測試使用帶有管道管理器的QNX4.1的預設安裝。

UNIX基準測試使用DELL SVR4 v2.1 UNIX的預設安裝。

QNX和DELL UNIX都是在多使用者模式下運作的。QNX系統使用固定的2MB大小的緩存，DELL系統使用SVR4預設的緩存算法。

結果：

核心調用：

QNX	UNIX	Ratio
umask	umask()系統調用（umask調用數每秒）	10560	28743	0.37
Yield	Yield()系統調用（yield調用數每秒）	99760	n/a	3.49	①
message	消息傳遞（消息數每秒）	26296	1887	13.9	②

①	由于Yield()調用是在POSIX 1003.4中定義的，并且在DELL UNIX下不受支援，是以我們假設如果它受到支援，UNIX核心将能夠像umask()調用一樣快速地執行它。這個假設使我們能夠計算出一個比較的比率。QNX下的Yield()核心調用的實作方式與UNIX中的umask()核心調用大緻相當，可以很好地比較核心入口開銷。
②	QNX使用它的原生Send()/Receive()/Reply()消息傳遞原語，而UNIX使用它的标準消息傳遞工具。

管道I/O：

塊大小	QNX	UNIX	Ratio
1024位元組（位元組每秒）	1948398	916598	0.37
16384位元組（位元組每秒）	3886920	2114722	3.49

順序檔案I/O：

使用8192位元組的read()和write() 系統調用，寫入一個16MB的檔案，然後再讀出來。在UNIX UFS和S5-1K兩種檔案系統上進行了測試。

QNX	UNIX UFS	Ratio
讀（位元組每秒）	1430404	289811	4.94
寫（位元組每秒）	777875	262513	2.96

QNX	UNIX S5-1K	Ratio
讀（位元組每秒）	1430404	175200	8.16
寫（位元組每秒）	777875	60068	12.95

QNX網絡吞吐量

測量從一個節點上的使用者程序，通過私有的兩節點網絡，到第二個節點上的使用者程序的資料傳輸速率。每個節點都是33MHz 386計算機。

Arcnet令牌總線理論最大值：	200,800 位元組每秒	2.5兆比特每秒
單令牌總線	190,000 位元組每秒	95%的效率
雙令牌總線	380,000 位元組每秒	95%的效率

以太網理論最大值：	1,185,840 位元組每秒	10兆比特每秒
以太網	960,000 位元組每秒	81%的效率

熟悉此類處理器在以太網上NFS的傳輸速率的讀者，肯定會喜歡這些性能資料。

原文連結：

https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf

翻譯連結：

版權聲明：本文為CSDN部落客「nibiewuxuanze」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：https://blog.csdn.net/nibiewuxuanze/article/details/103535875