目前的絕大多數操作系統，都是從單 CPU 的硬件開始起家的。因此，內核的同步模型，基本上都是針對中斷處理程序、 I/O 導致的阻塞所產生的並發，而非真正的並行處理而設計。一般來說，這種模型包括了“禁止中斷”，有時還包括“中斷優先級”以便處理不同的優先級和選擇性搶占，以及用以處理同步操作，如使內核線程進入休眠狀態的 I/O 等的簡單的休眠鎖。正如你已經猜到的那樣，這也是 BSD，包括 FreeBSD 開始這些工作的起點。
因此，在操作系統中引入 SMP 支持的第一步，往往就是引入“全局鎖（Giant lock）”，使內核在同一時刻事實上只在一顆 CPU 上運行。這樣做的目的是在 SMP 硬件上運行時，能夠依然使用 UP（單處理器）內核的那些基本假設。這使得用戶態程序能夠運行在多個 CPU 上，但內核則不能以並行方式運行。在內核中引入這種變動相對而言比較容易，因為它不需要改變整個內核的同步模型，而只需簡單地加入全局鎖、修改硬件探測和引導代碼，處理中斷傳遞、TLB shootdown等等。但是，由於內核無法從並行處理中獲益，因此對於高度依賴內核的操作而言，啟用 SMP 除了增加開銷之外，意義不大。
因此，引入 SMP 支持的下一個步驟，便是修改內核的同步模型，使得它的一些部分能夠在多個 CPU 上同時運行，並由此帶來性能提升。對於 FreeBSD 而言，全局鎖是在 FreeBSD 3 引入的，我們在 FreeBSD 5 中開始將其細化。在 FreeBSD 6 中，內核的絕大多數子系統都已經不再使用全局鎖，而在 FreeBSD 7 中，鎖的細化進行了更進一步的推進。現在還有一些邊角的位置上存在全局鎖，不太常用的文件系統、一些較舊的設備驅動，等等，但多數情況下，已經不會再看到正在運行由全局鎖保護的代碼了。需要說明的是，即使只是將內核中 1/2 的部分中的全局鎖細化，也會顯著地改善全局鎖保護的代碼性能，因為鎖的沖撞機會減少了。
目前，全局鎖已經逐漸被弱化成了保護 tty、 newbus、 usb 和 msdosfs 代碼的鎖，並且，消除全局鎖的工作，已經帶來了顯著的性能提升。在 FreeBSD 7 中，我們的工作重點，已經從消除全局鎖，轉移到了優化上鎖原語、調度器以及鎖粒度上。例如，在 FreeBSD 7 上 MySQL 的性能改進，多數都歸功於下面幾個有限的變動：
由 M:N 線程轉為 1:1 線程模型。
對於 sx(9) 休眠鎖原語的大幅改進。
引入了高效的非休眠 rw(9) 上鎖原語。
將內核中文件描述符表的上鎖方式改為使用低開銷的 sx(9) 原語，以及通過將上鎖操作細分為讀寫兩種所帶來的改善。
將 UNIX domain socket 改為細粒度上鎖模型。
由於引入 ule(4) 調度器帶來的大幅可伸縮性改善。
在 FreeBSD 8 中，我們將繼續對上鎖粒度和內核並行性方面進行改進，以更好地在更多 CPU 池中分攤負載。多核、多處理器芯片正在迅速普及，因此多處理器系統的性能非常值得深入挖掘。也就是說，盡管目前我們所做的工作已經取得了相當大的成效，我們仍然需要繼續挖掘多處理器硬件，特別是在網絡協議棧方面的潛能。
很是喜歡FreeBSD，目前FreeBSD7.0RC1已經發布，FreeBSD7.0即將發布，FreeBSD7在多核系統上的性能較之以前版本有很大的提高，而且已經位於主流操作系統前列。
通過PostgreSQL和MySQL的性能測試。
Linux 2.6.22 比 FreeBSD 7.0 慢了15%。
同時，PostgreSQL 比MySQL快了 35% - 45%。估計PostgreSQL8.3出來後，會把MySQL斃得滿地找牙。哈哈。
相信也期待FreeBSD8會有更大的改進。
