為了只將 Samba 一部分的程式碼，process_smb 與 recvive_smb 遷移到核心，
我們實作一個新的系統呼叫，作為進入核心及退出核心的介面。但系統呼叫最多 心。gcc library 中針對不同的帄台有不同的方法，因方法過多，我們只遷移實驗帄 台 i386 所用的 library。
將 Samba 遷移進核心後，還存在者兩次的資料複製，接者我們針對於影響效 能較大的資料複製做修改。資料複製於核心中主要由兩個函式控制，copy_to_user 及 copy_from_user，我們將資料複製改以指標的方式，將 user buffer 及 file system cache 指向 socket buffer。
遷移到核心後，我們利用 Iometer 於客戶端產生不同大小的寫入要求，來進行 utilization，結果我們看到只有在 128KB 時 CPU utilization 有明顯的下降，大於 128KB 的 request file size 卻沒有明顯的減少，於是我們進一步分析改善後系統資源
39
分布的狀況，於圖表 33 我們得知，就 sys 所佔的時間而言，隨著 request file size 越大所降低的比例也越多，zero-copy 確實減少了 CPU 的負擔，但 CPU utilization 卻沒有隨 request file size 越大而越少，於圖表 33 得知 softirq 經過我們改善後反而 比改善前花費了較多時間，因而造成了 CPU utilization 沒有如預期的隨 request file size 越大而越少。但就 sys 所花的時間來看，我們成功的將 sys 所花的時間從 49%
降低到了 40%。有效降低了 CPU 於資料複製的負擔。
圖表 32 one-copy 與 zero-copy 的 speedup（1 outstanding I/O）
40
圖表 33 改善前後之系統狀態（1 outstanding I/O）
6.2 伺服器滿載的情況系統效能的改善
接著由圖表 34 我們得知在 CPU 滿載的情況下，因所處理的資料量增加，如 有多餘的 CPU 資源可用，輸出也可相對的提高。由於我們改善了資料複製使得 CPU 使用率於 1 個 outstanding I/O 下較原本的低，於 128KB 可明顯的看到 CPU 資源完 全利用的時候改善的幅度從原本的 23%上升到了 27%，而 1MB 的情況因為原本於 1 個 outstanding I/O 的情況下就已沒餘下多少 CPU 資源，故於 32 outstanding I/Os 的情況下沒辦法有明顯的成長。從 32KB request file size 到 1MB request file size，
one-copy 可以有 1.05~1.07 的 speedup，而 zero-copy 更可達到 1.11~1.28 的 speedup。
接著我們再進一步分析伺服器滿載的情況下資源的分配情形，於圖表 35 可看 出於較大的 request file size 下，我們成功將 sys 所花的時間從 51%降低到了 42%，
有效降低了 CPU 負荷滿載情況下資料複製的負擔。並發現 softirq 與效能成正比的 一個關係。
41
圖表 34 one-copy 與 zero-copy 的 speedup（CPU 滿載的情況）
圖表 35 改善前後之系統狀態（CPU 滿載的情況）
42 現處理網路部分最上層的函式為 net_rx_action，故我們針對於 net_rx_action 函式的 進入點與退出點分別插入 probe，加入時間的資訊，並加以收集（圖表 36）（圖表 37）。接著評估於 512B 到 1MB 於網路處理所花的時間。以下為我們所評估的主要 數學式，由 Iometer 我們可以得知 bandwidth、response time、IOPS，其中 IOPS 又 與 response time 成反比，因此我們求出網路所花的時間後，再與 response time 相 除得到網路所佔的比例（cost%），接著原本的 bandwidth 再除以改善後所需花費的 時間比（1-cost%），所得的結果即為加入 TOE 後所能達到的 bandwidth，由以下的 算式做出預測：
bandwidth = request size * IOPS = request size / response time network cost% = cost of netwrok / response time
bandwidth with TOE = bandwidth_original /（1 - network cost%）
根據這預測，我們假設 TOE 能解決所有網路處理的時間，並加以評估。於圖