LinuxIO數(shù)據(jù)通道分享

1.IO數(shù)據(jù)通道處理層次2.塊IO層——截獲IO3.IO調(diào)度4.中斷和中斷處理

5.總結(jié)目錄IO數(shù)據(jù)通道處理層次VFSLayerNFSext2ext3NTFSPagecacheGenericBlockLayerI/OSchedulerLayerBlockDeviceDriverLayerBlockDeviceLayer系統(tǒng)調(diào)用1、IO數(shù)據(jù)通道處理層次：塊IO子系統(tǒng)塊設備：塊設備是支持以固定長度的塊為單位讀/寫數(shù)據(jù)的存儲設備的總稱。塊設備包括支持隨機訪問（如數(shù)碼相機存儲卡，RAM盤）和尋到的硬件設備（如磁盤、軟盤、CDROM、內(nèi)存區(qū)域等），也可以是邏輯設備，如MD設備，Devicemapper。注冊塊設備：一、

分配,初始化請求隊列,綁定請求隊列和請求函數(shù)；二、分配,初始化gendisk,給gendisk的major,fops,queue等成員賦值,最后添加gendisk.；

三、注冊塊設備驅(qū)動。注銷塊設備：一、

清除請求隊列.二、

刪除gendisk和gendisk的引用三、刪除對塊設備的引用,注銷塊設備驅(qū)動.塊IO層——截獲IO塊設備處理請求函數(shù)：請求處理是塊設備驅(qū)動的核心，實際的工作都是在這個函數(shù)執(zhí)行，是塊設備驅(qū)動提供給上層的借口，塊設備將通過這個函數(shù)獲得I/O請求。請求函數(shù)原型：intmake_request(structrequest_queue*

q,

struct

bio*

bio);或intmake_request(structrequest_queue_t*

q);塊IO層——截獲IOstructrequest{ structlist_headqueuelist; structrequest_queue*q; unsignedintcmd_flags;//請求的類型 sector_t__sector; //請求開始扇區(qū) unsignedint__data_len; 請求的數(shù)據(jù)長度 structbio*bio;請求的第一個bio structbio*biotail;請求的最后一個bio……………….};請求的幾個重要結(jié)構(gòu)：structrequest_queue{ structlist_head queue_head;//請求隊列 request_fn_proc *request_fn;// make_request_fn *make_request_fn;//請求處理函數(shù)unsignedlong queue_flags;//請求標志unsignedlong nr_requests;請求隊列中最大請求數(shù)spinlock_t *queue_lock;自旋鎖…………….};塊IO層——截獲IOstructbio_vec{ structpage *bv_page; unsignedint bv_len; unsignedint bv_offset;};請求的幾個重要結(jié)構(gòu)：structbio{sector_t bi_sector; structbio *bi_next; /*requestqueuelink*/ unsignedlong bi_rw; unsignedshort bi_vcnt; /*howmanybio_vec's*/ unsignedshort bi_idx; structbio_vec *bi_io_vec;//請求數(shù)據(jù)的數(shù)據(jù)存放位置…………….};塊IO層——截獲IOrequest_queuerequestbiobiobio_vecbio_vecbio_vecqueue_headBio_vecbiotailBio_vecBv_pageBv_pageBv_pageBioBi_nextq_sectorBi_sectorBi_sector塊IO層——截獲IO分配,初始化請求隊列,綁定請求隊列和請求函數(shù)的兩種方式：

一.無請求隊列：適合于完全可以隨機訪問的設備數(shù)碼相機存儲卡，RAM盤等（現(xiàn)在我們的SSD適合），這種方式不會經(jīng)過IOScheduleLayer。分配請求隊列、綁定請求隊列和請求函數(shù)：blk_alloc_queue——分配請求隊列；Blk_queue_make_request(xxx_request_queue,make_request)——綁定請求隊列和請求函數(shù)塊IO層——截獲IO分配請求隊列、綁定請求隊列和請求函數(shù)：blk_init_queue(make_request，queue_lock)——分配請求隊列且綁定請求隊列和請求函數(shù)。二.有請求隊列：適合于機械磁盤設備，使用請求隊列可以提高系統(tǒng)的性能，會經(jīng)過IOScheduleLayer。塊IO層——截獲IOIO調(diào)度層

IO調(diào)度層：接收上層發(fā)出的I/O請求，緩存請求并試圖合并相鄰的請求，并根據(jù)設置好的調(diào)度算法，回調(diào)驅(qū)動層提供的請求處理函數(shù)，以處理具體的I/O請求。NOOPCFQDeadlineAnticipatory實現(xiàn)了最最簡單的FIFO隊列,所有IO請求大致按照先來后到的順序進行操作.之說“大致”,原因是NOOP在FIFO的基礎上還做了相鄰IO請求的合并,并不是完完全全按照先進先出的規(guī)則滿足IO請求按照IO請求的地址進行排序,而不是按照先來后到的順序來進行響應.除了CFQ本身具有的IO排序隊列外,DEADLINE額外分別為讀IO和寫IO提供了FIFO隊列.ANTICIPATORY的在DEADLINE的基礎上,為每個讀IO都設置了6ms的等待時間窗口.如果在這6ms內(nèi)OS收到了相鄰位置的讀IO請求,就可以立即滿足Linux的四種I/O調(diào)度算法IO調(diào)度層

IO調(diào)度的流程：__make_request中斷和中斷處理硬件（如鍵盤）中斷控制器處理器處理器中斷內(nèi)核do_IRQ()該線上是否有中斷處理程序handle_IRQ_event在該線上運行所有的中斷處理程序ret_from_intr()產(chǎn)生一個中斷否是中斷：中斷是指在CPU正常運行期間，由于內(nèi)外部事件或由程序預先安排的事件引起的CPU暫時停止正在運行的程序，轉(zhuǎn)而為該內(nèi)部或外部事件或預先安排的事件服務的程序中去，服務完畢后再返回去繼續(xù)運行被暫時中斷的程序。Linux中通常分為外部中斷（又叫硬件中斷）和內(nèi)部中斷（又叫異常）。中斷和中斷處理中斷處理：中斷處理程序要求快速、高效，而又想中斷處理程序處理的工作量多，所以把中斷處理分成中斷上半部和下半部。上半部：有嚴格時限的工作，如：對接收中斷進行答復或復位；下半部：可以稍后或者說可以延遲一點的工作；中斷處理程序：操作系統(tǒng)在響應一個中斷的時候，內(nèi)核會執(zhí)行一個函數(shù)，該函數(shù)，這個函數(shù)就是中斷處理程序。中斷和中斷處理注冊中斷處理函數(shù)原型：

intrequest_irq(unsignedintirq,irq_handler_thandler, unsignedlongflags,constchar*devname,void*dev_id)釋放中斷處理函數(shù)原型：voidfree_irq(unsignedintirq,void*dev_id)Irq：表示要分配的中斷號；handler：中斷處理函數(shù)；Flags：中斷處理程序標志；如IRQ_DISABLED，IRQ_SHARED等；Name:中斷相關設備的名字；Dev_id:用于共享中斷線：注冊、釋放中斷處理程序：驅(qū)動處理程序可以通過request_irq()函數(shù)注冊一個中斷處理程序，并且激活中斷線，以便處理中斷。中斷和中斷處理三、工作隊列：二、tasklet:中斷下半部實現(xiàn)機制：一、軟中斷：中斷和中斷處理軟中斷的實現(xiàn):軟中斷是在編譯期間靜態(tài)分配的，它由softirq_action的結(jié)構(gòu)表示：structsoftirq_action{void(*action)(structsoftirq_action*);};軟中斷處理程序:軟中斷處理程序action的函數(shù)原型如下：Voidsoftirq_handler(structsoftirq_action*)當內(nèi)核運行一個軟中斷處理程序時，它會執(zhí)行這個action函數(shù)。

中斷和中斷處理中斷和中斷處理執(zhí)行軟中斷:一個注冊的軟中斷必須被標記后才會執(zhí)行，這叫觸發(fā)軟中斷，通常，中斷處理程序會在返回結(jié)束前會觸發(fā)軟中斷，使其在稍后被執(zhí)行。觸發(fā)軟中斷的函數(shù)是：raise_softirq_irqoff();

raise_softirq();

中斷上半部、下半部的例子：SCSI子系統(tǒng)中斷上半部：scsi_done——中斷處理函數(shù)最終會調(diào)用的回調(diào)函數(shù)；blk_complete_request——一個結(jié)束請求的函數(shù)，會觸發(fā)軟中斷；到此中斷上半部結(jié)束；中斷下半部：（軟中斷機制）blk_done_softirqscsi_softirq_donescsi_finish_commandscsi_io_completionscsi_end_requestblk_end_iobio_endio。中斷和中斷處理工作隊列：工作隊列是另一種將工作推后執(zhí)行的形式，它可以把推后執(zhí)行的工作交給一個內(nèi)核線程來執(zhí)行，也就是用這種機制實現(xiàn)中斷下半部的是在進程上下文中執(zhí)行的，工作隊列可以重新調(diào)度甚至睡眠。工作隊列的實現(xiàn)：工作隊列子系統(tǒng)是一個用于創(chuàng)建內(nèi)核線程的接口，通過它創(chuàng)建的進程負責由內(nèi)核其他部分排到隊列里的任務。它創(chuàng)建內(nèi)核線程稱為工作者線程。工作隊列線程可以讓你的驅(qū)動程序創(chuàng)建一個專門的工作者線程來處理推后執(zhí)行的工作。同時也提供一個缺省的工作者線程來處理這些操作。表示線程的數(shù)據(jù)結(jié)構(gòu)：中斷和中斷處理表示線程的數(shù)據(jù)結(jié)構(gòu)：structworkqueue_struct{ structcpu_workqueue_struct*cpu_wq; structlist_headlist; constchar*name; intsinglethread; intfreezeable; /*Freezethreadsduringsuspend*/ intrt;#ifdefCONFIG_LOCKDEP structlockdep_maplockdep_map;#endif};表示工作的數(shù)據(jù)結(jié)構(gòu)：structwork_struct{ atomic_long_tdata; structlist_headentry; work_func_tfunc;};中斷和中斷處理使用工作隊列：一、創(chuàng)建推后執(zhí)行的工作：1、靜態(tài)創(chuàng)建：DECLARE_WORK(name，void

(*func)(void*),void*data);2、動態(tài)創(chuàng)建：INIT_WORK(structwork_struct*work,oid

(*func)(void*),void*data);二、工作隊列處理函數(shù)：工作處理函數(shù)的原型：voidwork_handler(void*data);不能訪問用戶空間。中斷和中斷處理三、對工作進行調(diào)度：把給定工作的處理函數(shù)提交給缺省的events工作者線程：

schedule_work();

調(diào)用此函數(shù)work馬上會被調(diào)度，當所在處理器上的工作隊列線程被喚醒時就會被執(zhí)行；中斷和中斷處理中斷和中斷處理

工作隊列實際例子：如：擦除命令中斷上半部：Mvumi_isr_handler()——中斷處理函數(shù)；Mvumi_launch_events()——創(chuàng)建將要推后執(zhí)行的工作，調(diào)用schedule_work(),調(diào)度work把給定的工作的處理函數(shù)提交給缺省的events工作者線程

，最后調(diào)用mvumi_complete_internel_cmd——中斷處理程序上半部結(jié)束，喚醒發(fā)送內(nèi)部管理命令的線程。中斷下半部：工作隊列機制缺省的events工作者線程，當該線程被喚醒時，會處理執(zhí)行推后處理的work。下半部機制的選擇：首先，如果需要一個可以休眠、可以調(diào)度的實體來執(zhí)行推后完成的工作，選擇工作隊列；否則用tasklet,還有如果專注性能的提高，可以使用軟中斷。

下半部

上下文

順序執(zhí)行保障

接口復雜度

軟中斷

中斷

沒有

復雜tasklet

中斷同類型不能同時執(zhí)行

次之

工作隊列

進程沒有（進程一樣）

最簡單實現(xiàn)下半部機制比較中斷和中斷處理中斷和中斷處理實際實現(xiàn)：對于普通讀寫和trim命令中斷處理只有上半部：Mvumi_isr_handlermvumi_receive_ob_list_entryg_complete_cmdraid0_end_iohost_cmd_donebio_endio關于在調(diào)試trim命令時mkfs.xfs/dev/sdb–f時出現(xiàn)堆棧,但是系統(tǒng)能夠正常運行且不影響數(shù)據(jù)一致性，當時找不到原因，現(xiàn)在懷疑就是trim命令中斷處理程序只有上半部，導致中斷處理程序不及時高效所致；此猜想的依據(jù)：現(xiàn)在在注冊成有請求隊列的塊設備的代碼結(jié)束請求的函數(shù)用blk_end_request_all,曾經(jīng)出現(xiàn)和調(diào)試trim命令時一樣的情況，參考內(nèi)核源碼