第二部分端節(jié)點算法學(參考版)
2024-08-12 13:07本頁面
【正文】 。 ? 運用 P1原則要求對整個系統(tǒng)有一個概要的了解，使用簡單的模型（硬件、體系結(jié)構(gòu)、操作系統(tǒng)、協(xié)議）就可以做到這一點。 小結(jié) ? 本章以 web應(yīng)用為例介紹了優(yōu)化內(nèi)存和總線帶寬使用的技術(shù) ，主要包括： ? 使用適配器內(nèi)存消除 copy 4 ? 使用 fbufs消除 copy 3 ? 使用 mmap消除 copy 2 ? 使用 IOLite、 sendfile消除 copy2 和 copy 3 ? 整合拷貝和檢查和計算到 一個循環(huán)中 ? 通過代碼重新布局、局部性驅(qū)動的協(xié)議層處理優(yōu)化 Icache的使用 本章使用的技術(shù)以及主要的原則 P1原則的運用 ? 本章反復應(yīng)用 P1原則來消除明顯的浪費： ? 不必要的讀和寫消耗了內(nèi)存和總線帶寬 。 ? 當一個協(xié)議層被調(diào)用時，從自己的讀隊列中取數(shù)據(jù)包，直至隊列取空 。 ? 通過安排代碼在內(nèi)存中的位置優(yōu)化常見情形（ P11），使得最常使用的代碼駐留在 Icache中 新的問題 ? 處理包的協(xié)議代碼肯定無法全部裝入指令cache： ? Icache的容量非常有限 ? 計算機上的所有程序都要競爭 Icache ? 問題： ? 每處理一個包，就要將全部的協(xié)議代碼裝入指令 cache一次， 效率太低?。? 局部性驅(qū)勱的協(xié)議層處理 ? 基本 思想 ： ? 每個協(xié)議層 一次處理多個包，分攤裝載 Icache的開銷 ? 每一批 處理的 包數(shù)量越 多 ， Icache的使用越高效 ? 具體實現(xiàn)時，應(yīng)能 動態(tài)調(diào)整批處理的大小 軟件工程方面的考慮 ? 代碼重新組織可以讓編譯器來做 ： ? 程序員對 不常使用的 代碼 分支 進行標注 ，由 編譯器為 Icache重新組織代碼 。 ? 如 果 X 和 Z 位于同一個指令塊中，取經(jīng)常使用的代碼 X，會把不經(jīng)常使用的代碼 Z 也取進來， 浪費了內(nèi)存帶寬和 cache空間。 （基于空間局部性假設(shè)而優(yōu)化） ? 問題： ? 不常用的代碼會被讀入 Icache，如果它與常用代碼在一個塊中。 ? 問題： ? 被映射到 Icache同一位置 的代碼 會被 輪流 替換出去，即使它們都是經(jīng)常使用的代碼 。 ? 結(jié)論： ? ILP很難實現(xiàn)（問題 1~問題 3） ? ILP可能性能不佳（問題 4） ? ILP可能完全沒有必要（若包數(shù)據(jù)需要被處理幾次，則數(shù)據(jù)很可能駐留在 cache中） 擴展到數(shù)據(jù)操作乊外 ? 消除數(shù)據(jù)拷貝和整合數(shù)據(jù)操作，其技術(shù)共同點都 是避免冗余的讀 /寫 操作，以 減少對內(nèi)存總線的壓力。比如，如果數(shù)據(jù)包的 TCP檢查和驗證失敗，就不應(yīng)當對包進行解密操作。 ? 整合層次處理會有什么問題？ ILP面臨的問題 ? 問題一： ? 不同操作需要的信息一般來自不同的層次 ， 將不同層次的代碼整合在一起而不犧牲模塊化 特性 極其困難 ? 問題二： ? 不同操作可能需要在不同長度的數(shù)據(jù)塊上 以及 數(shù)據(jù)包的不同部位進行 。 內(nèi)核 sendfile實現(xiàn) ? 調(diào)用 sendfile()時： ? 文件數(shù)據(jù) 先 被 拷貝到內(nèi)核中的文件 緩沖區(qū) ? 然后 從 文件 緩沖區(qū) 拷貝到 內(nèi)核中 的 socket緩沖區(qū) ? 最 后 從 socket緩 沖區(qū) 拷貝 到適配器 ? 與 read/write方式相比，減少了一次拷貝 內(nèi)核版本 sendfile實現(xiàn) ? 調(diào)用 sendfile()時： ? 文件數(shù)據(jù) 先 被 拷貝到內(nèi)核中的文件 緩沖區(qū) ? 將記錄數(shù)據(jù)位置和長度的信息保存到 socket緩沖區(qū) ? 數(shù)據(jù)通過 DMA通道直接發(fā)送到適配器 ? 消除了 copy 2 和 copy 3 ? 基于 sendfile的機制不能推廣到與 CGI程序通信 ? Sendfile() 已用于 apache、 nginx、 ligd等web服務(wù)器中 擴展到拷貝乊外 ? 利用 load和 store之間的 空周期做 累加 計算，不需額外開銷，拷貝循環(huán)可以擴展到 包括 檢查和計算。 write (socket, tmp_buf, len)。 ? IOLite必須實現(xiàn)一個復雜的替換策略 ： ? IOLite頁既可能是虛擬內(nèi)存頁 又 可能是文件頁 ? 需 將標準的頁替換規(guī)則和文件緩存替換策略集成在一起 。 ? 將 改良后的管道 應(yīng)用到 CGI程序和 web服務(wù)器之間，可 以 消除 冗余的 拷貝 。 ? IOLite給每個緩沖區(qū)分配一個編號， TCP模塊維護一個以緩沖區(qū)編號為索引的檢查和 高速緩存 。 ? 當應(yīng)用發(fā)送文件給 TCP時， 網(wǎng)絡(luò) 子 系統(tǒng)得到一個指向相同IOLite頁的指針。 ? IOLite可以一攬子解決前面所有的問題： ? 消除 copy 2和 copy 3 ? 消除 CGI程序和 web服務(wù)器之間的拷貝 ? 緩存?zhèn)魉瓦^的數(shù)據(jù)包的檢查和 IOLite 的主要思想 ? IOLite 借用了 fbufs 的主要思想： ? 為同一條路徑上的進程映射相同的物理頁，實現(xiàn) 只讀共享 ? 推遲創(chuàng)建路徑的緩沖區(qū) ? 使用緩沖區(qū)聚合 以允許添加包頭 IOLite 響應(yīng)
職業(yè)教育相關(guān)推薦
鄂ICP備17016276號-1