根據前一章的探測資料，我們得知每次一個客戶端的要求寫入，都會花費 6 次的系統呼叫，第一次 sys_read 讀取資料長度，第二次 sys_read 讀取資料，第三 次 sys_pwrite 寫入 disk buffer，第四次 sys_write 回應客戶端，第五次 sys_gettimeofday 取得時間資訊，第六次 sys_select 等待下一次要求。如果要求寫入的檔案大小較小，
每次要求都需要 6 次的 system call，context switch 的增加，造成了 CPU 的負擔。
其次對於要求較大的檔案而言，context switch 造成的影響就沒那麼大，但是 資料複製（data copy）卻是另外一個值得探討的問題，每一次的寫入要求 CPU 都 必須將資料從 socket buffer 複製到 user buffer，Samba 處理過後再將資料從 user buffer 複製到 disk buffer。然而對於嵌入式 Samba 伺服器而言，這複製的動作是可 以省略的，因為資料並不會遭到更動，大量的複製反而造成了 CPU 的負擔。
為了解決上述這兩點問題，我們決定將 Samba 處理資料的主要程式遷移到核 心空間（kernel space），以達到 zero-copy 解決 context switch 以及資料複製的問題。
5.1 評估遷移路徑
經由上述的工具我們整理出 SMB 寫入流程圖（圖表 29）。Samba 初始化完後，
呼叫 sys_select 的系統呼叫，等待來自於客戶端的要求；收到要求後，sys_select 回傳，Samba 開始接收資料，先呼叫第一個系統呼叫 sys_read，從 socket buffer 複 製 4byte 的資料到 user buffer，並根據這資料得到資料的長度並加以判斷是否長度 大於零；接著進行第二次系統呼叫 sys_read，複製經由前一次系統呼叫所取得的長 度的資料，因 TCP receive buffer 及 send buffer 的限制，故一次最多處理 64KB 的 資料；接著資料複製到 user buffer 後，Samba 進行資料的處理，分析客戶端的命令，
並實行不同的運作方式，若客戶端運行寫入，則資料處理完後即呼叫 sys_pwrite64 將資料寫入到檔案系統，成功寫入後接著呼叫 sys_write 回報訊息給客戶端；接著 設定 sys_select 的等待時間，進入等待下一個來自客戶端的要求。若客戶端要求寫
35
入的大小為 1MB 則依照上述的運作，重複 16 次。
為了將 Samba 處理資料的主要程式遷移到核心空間，我們需要知道 Samba 及 核心之間相互的行為，因此我們藉由 Dtrace 及 SystemTap 所追蹤到的資料，進一 步探討 Samba 寫入的行為。我們將 Samba 與核心間的行為，以系統呼叫為分界，
做遷移的評估。Samba 寫入行為中，有兩次系統呼叫為 sys_read，讀取 socket buffer 的資料到 user buffer，及 sys_pwrite64，將 user buffer 資料寫入到 disk buffer。為了 將這兩次的資料複製消除掉，我們必須知道 Samba 是如何處理這些系統呼叫的。
因此我們利用 Dtrace 加上 SystemTap 得知 Samba 與核心追蹤的資料，並加以分 析，如圖表 30 所示較為重要的兩個函式為 receive_smb 與 process_smb，這兩個函 式就包含了 4 次的系統呼叫，而其中兩次系統呼叫更是我們所關心的資料複製。
Samba 中最主要的 user buffer 部分包含於這兩個函式，若我們將這兩個函式遷移到 核心，可免除 Samba 與核心間資料同步的問題。於是我們決定創造一個新的系統 呼叫將最主要的兩個函式遷移到核心，以減少 6 次的 context switch 以及 2 次的資 料複製 。
36
圖表 29 SMB 寫入之流程圖
圖表 30 遷移流程圖
37
5.2 評估效能改善的程度
在將 Samba 的主要程式遷移到 kernel space 之前，我們對於減少資料複製，做 一個簡易的評估。為了能快速的評估，我們利用 Strace，紀錄所有系統呼叫所花費 的時間。由於牽涉資料複製的兩個系統呼叫分別為 sys_read 與 sys_pwrite64，我們 由此概略估計資料複製所佔整個資料處理的比例，再以下列算式評估移除資料複 製過後可能的效能改善：
bandwidth = request size * IOPS = request size / response time cost% = cost time / response time
bandwidth_improved = bandwidth_original / （1 - cost%）
就小檔案而言，因為大部份的時間並不是花在資料複製的時間，所評估出來的時 間為不含資料複製之系統呼叫所花的時間；就大檔案而言，則概略評估系統呼叫 的時間為資料複製時間。
由圖表 31 顯示，於大檔案傳輸的情況下，若是利用 zero-copy，最高可達到
~60MBps 的輸出，將近 65%的效能改善，於是我們開始著手進行遷移。
圖表 31 zero-copy 與 one-copy 輸出預測
38