亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: FreeBSD支持SMP否???? [打印本頁]

作者: leaner    時間: 2004-01-07 00:41
標題: FreeBSD支持SMP否????
我們服務器裝的LINUX
只有一個CPU
但是可以用SMP的
top的時候 可以看到2個CPU

現(xiàn)在想改成FreeBSD的系統(tǒng)
不知道FreeBSD支持這樣么?
剛才搜索了一下 信息很少 好象不可以的樣子
作者: feelfirst    時間: 2004-01-07 00:57
標題: FreeBSD支持SMP否????
暈怎么不可以啊,,
偶P4 2.4 CG就是SMP的
編譯內核的時候支持一下就可以啊/
作者: solaris007    時間: 2004-01-07 17:38
標題: FreeBSD支持SMP否????
需要重新編譯內核
去掉下面兩行前面的#:
options SMP
options APIC_IO
如果是超線程的SMP還需要把下面這行前面的#去掉:
options HTT
作者: leaner    時間: 2004-01-10 18:58
標題: FreeBSD支持SMP否????
要到5.X版SMP支持才好,不知道是么?
作者: 書劍飄零    時間: 2004-01-10 19:19
標題: FreeBSD支持SMP否????
5.x對SMP的支持是好d~ :em11: :em11: :em11:

http://www.cnfug.org/project/ffs/contents.html

《FreeBSD使用大全》第二版    作者:王波


1.5.1 下一代SMP支持

對于高端服務器來講,不再是單處理器的系統(tǒng),而是使用了多個中央處理器共同執(zhí)行計算任務。目前,服務器通常使用的是SMP方式,就是說多個處理器處于等價的地位,可以訪問同樣的內存空間,有相同的機會同時處理計算任務。因此對于SMP系統(tǒng),原則上就可以將多個計算任務同時分配給多個處理器同時進行,達到提高系統(tǒng)性能的目的。

然而,事情總不是那么簡單的,因為如果希望計算任務能夠被很好的并行處理,那么計算任務應該能劃分為很多個互不相關的子任務,這樣才能同時提供給多個處理器進行處理,滿足并行處理的需要。如果計算任務不能劃分為這樣的多個子任務,這樣就可能出現(xiàn)一個處理器工作的時候,另一個處理器由于必須等待而處于空閑狀態(tài)的情況,這樣,系統(tǒng)性能就不能像理想中的那樣成倍增加。

由于Unix本身是多任務的,系統(tǒng)本身就存在多個進程,最簡單的考慮是每個處理器可以處理一些進程對應的任務,達到并行處理的目的。然而,這些進程可以通過系統(tǒng)調用進入內核空間執(zhí)行任務,內核本身也會執(zhí)行相應的處理任務,當計算任務進入內核當中,問題就比較復雜了。

因為傳統(tǒng)的Unix的內核是不可搶占的,一個內核任務和用戶進程任務是不同的,一旦執(zhí)行一個內核任務,就必須等待這個任務執(zhí)行完畢才能執(zhí)行下一個內核任務。例如硬件中斷處理,由于硬件資源的唯一性,必須等待一個處理任務處理完畢之后,才能進行下一個中斷處理。但事實上很多內核任務還是可以同時處理的,例如對不同硬件的處理等等。因此如果在Unix中增加SMP支持,就需要解決這個內核的計算任務的并行化問題。

并行化的關鍵就是對一些硬件資源進行加鎖保護,以防止對同一個資源的并發(fā)訪問,導致數(shù)據錯誤。在目前的FreeBSD系統(tǒng)中,采取的是比較簡單而且保守的策略,就是說對資源采用排他鎖的方式進行保護,一但內核任務出現(xiàn)沖突,就進行鎖定,而不管系統(tǒng)中是否還存在其他可以并行執(zhí)行的任務。這種排他鎖的做法雖然比較簡單,但由于大多數(shù)情況都是用戶進程的并行處理,內核操作的沖突比較少,還是能夠滿足并行處理的要求的。但在更復雜的情況下,例如存在大量系統(tǒng)調用或內核操作的情況下,這種簡單的策略就造成了很多本可以并行處理的內核操作不得不順序進行,使得系統(tǒng)的性能無法成倍的提升。

FreeBSD的這種簡單化的策略就使得目前版本的FreeBSD在高端服務器上的性能表現(xiàn)上并不是十分理想。因此在FreeBSD 5.0系列中,對于SMP的支持將完全重寫,這一部分工作稱為SMPng,它將參考商業(yè)的BSD/OS中的部分優(yōu)點,并移植BSD/OS中的一些代碼,從而使得對SMP的支持更為優(yōu)秀。

SMPng需要完成的目標就是能夠實現(xiàn)內核任務或中斷處理的可并發(fā)執(zhí)行,以充分利用多處理器的能力,當然這不可能在FreeBSD 5.0中完全解決,但5.0將提供一個很好的開始。首先需要完成的工作就是使用更精細的鎖定策略,很多操作系統(tǒng)的鎖定機制要比FreeBSD要好,例如在BSD/OS中,當一個處理器處理的內核任務不能執(zhí)行時,該處理器可以去執(zhí)行其他的處理任務,而不是簡單的鎖定。

但在SMPng中,所完成的工作事實上將更復雜,SMPng將保留原來系統(tǒng)的SMP支持中的排他鎖方式用來支持目前存在的內核處理,但添加了更復雜的調度鎖,以支持多處理器處理。進行鎖定處理的關鍵是資源的唯一性,一些資源在一個時間只能被一個任務進行處理,否則就可能發(fā)生不一致的問題,而如果將這個只能被唯一訪問的資源改變?yōu)槎嗦窂陀闷,多個計算任務就可以同時訪問它了,SMPng的調度鎖的實質就是這個目的。因此,接下來的工作就是查看所有的多處理器相關的內核代碼,將可能沖突的資源更改為新的調度鎖。

此外,SMPng中還要改善中斷處理例程,傳統(tǒng)的Unix中斷處理不可被中斷,這樣就不適合SMP的情況。SMPng中將改變中斷處理例程,使其具備上下文的屬性,使得中斷處理例程可以被再次中斷和重新進入。SMPng的這些復雜的工作,將使得中斷處理和其他內核操作中互斥的部分降低到最少,達到內核任務可以并行執(zhí)行的目的。顯然,SMPng的工作將明顯改善FreeBSD對于SMP的支持,改善FreeBSD在高端服務器系統(tǒng)上的性能。
作者: hdcola    時間: 2004-02-01 23:53
標題: FreeBSD支持SMP否????
原帖由 "solaris007" 發(fā)表:
需要重新編譯內核
去掉下面兩行前面的#:
options SMP
options APIC_IO
如果是超線程的SMP還需要把下面這行前面的#去掉:
options HTT

我的是HT的CPU,操作系統(tǒng)是4.9,把HTT的#去了,config時說沒有HTT,只去SMP和APIC_IO它就直接認出二個cpu了。
真是很奇怪的說。
作者: dennis2    時間: 2004-02-02 09:33
標題: FreeBSD支持SMP否????
原帖由 "hdcola" 發(fā)表:

我的是HT的CPU,操作系統(tǒng)是4.9,把HTT的#去了,config時說沒有HTT,只去SMP和APIC_IO它就直接認出二個cpu了。
真是很奇怪的說。


4.9 的 HTT 已經變成默認的了,所以就沒有該選項了:

[quote="/usr/src/UPDATING"]
...
20031028:
        FreeBSD 4.9-RELEASE.

20031022:
        Support for HyperThread logical CPUs has now been enabled by
        default.  As a result, the HTT kernel option no longer exists.
        Instead, the logical CPUs are always started so that they can
        handle interrupts.  However, the extra logical CPUs are prevented
        from executing user processes by default.  To enable the logical
        CPUs, change the value of the machdep.hlt_logical_cpus from 1 to
        0.  This value can also be set from the loader as a tunable of
        the same name.
...
[/quote]
作者: 9527    時間: 2004-02-02 10:47
標題: FreeBSD支持SMP否????
原帖由 "leaner" 發(fā)表:
我們服務器裝的LINUX
只有一個CPU
但是可以用SMP的
top的時候 可以看到2個CPU

現(xiàn)在想改成FreeBSD的系統(tǒng)
不知道FreeBSD支持這樣么?
剛才搜索了一下 信息很少 好象不可以的樣子




SMP不是至少兩個CPU才可以用嗎
為什么樓主1個CPU就可以用啊
那位說說啊?




歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2