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è)備：塊設(shè)備是支持以固定長度的塊為單位讀/寫數(shù)據(jù)的存儲設(shè)備的總稱。塊設(shè)備包括支持隨機(jī)訪問（如數(shù)碼相機(jī)存儲卡，RAM盤）和尋到的硬件設(shè)備（如磁盤、軟盤、CDROM、內(nèi)存區(qū)域等），也可以是邏輯設(shè)備，如MD設(shè)備，Devicemapper。注冊塊設(shè)備：一、

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

三、注冊塊設(shè)備驅(qū)動(dòng)。注銷塊設(shè)備：一、

清除請求隊(duì)列.二、

刪除gendisk和gendisk的引用三、刪除對塊設(shè)備的引用,注銷塊設(shè)備驅(qū)動(dòng).塊IO層——截獲IO塊設(shè)備處理請求函數(shù)：請求處理是塊設(shè)備驅(qū)動(dòng)的核心，實(shí)際的工作都是在這個(gè)函數(shù)執(zhí)行，是塊設(shè)備驅(qū)動(dòng)提供給上層的借口，塊設(shè)備將通過這個(gè)函數(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;請求的第一個(gè)bio structbio*biotail;請求的最后一個(gè)bio……………….};請求的幾個(gè)重要結(jié)構(gòu)：structrequest_queue{ structlist_head queue_head;//請求隊(duì)列 request_fn_proc *request_fn;// make_request_fn *make_request_fn;//請求處理函數(shù)unsignedlong queue_flags;//請求標(biāo)志unsignedlong nr_requests;請求隊(duì)列中最大請求數(shù)spinlock_t *queue_lock;自旋鎖…………….};塊IO層——截獲IOstructbio_vec{ structpage *bv_page; unsignedint bv_len; unsignedint bv_offset;};請求的幾個(gè)重要結(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分配,初始化請求隊(duì)列,綁定請求隊(duì)列和請求函數(shù)的兩種方式：

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

IO調(diào)度層：接收上層發(fā)出的I/O請求，緩存請求并試圖合并相鄰的請求，并根據(jù)設(shè)置好的調(diào)度算法，回調(diào)驅(qū)動(dòng)層提供的請求處理函數(shù)，以處理具體的I/O請求。NOOPCFQDeadlineAnticipatory實(shí)現(xiàn)了最最簡單的FIFO隊(duì)列,所有IO請求大致按照先來后到的順序進(jìn)行操作.之說“大致”,原因是NOOP在FIFO的基礎(chǔ)上還做了相鄰IO請求的合并,并不是完完全全按照先進(jìn)先出的規(guī)則滿足IO請求按照IO請求的地址進(jìn)行排序,而不是按照先來后到的順序來進(jìn)行響應(yīng).除了CFQ本身具有的IO排序隊(duì)列外,DEADLINE額外分別為讀IO和寫IO提供了FIFO隊(duì)列.ANTICIPATORY的在DEADLINE的基礎(chǔ)上,為每個(gè)讀IO都設(shè)置了6ms的等待時(shí)間窗口.如果在這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在該線上運(yùn)行所有的中斷處理程序ret_from_intr()產(chǎn)生一個(gè)中斷否是中斷：中斷是指在CPU正常運(yùn)行期間，由于內(nèi)外部事件或由程序預(yù)先安排的事件引起的CPU暫時(shí)停止正在運(yùn)行的程序，轉(zhuǎn)而為該內(nèi)部或外部事件或預(yù)先安排的事件服務(wù)的程序中去，服務(wù)完畢后再返回去繼續(xù)運(yùn)行被暫時(shí)中斷的程序。Linux中通常分為外部中斷（又叫硬件中斷）和內(nèi)部中斷（又叫異常）。中斷和中斷處理中斷處理：中斷處理程序要求快速、高效，而又想中斷處理程序處理的工作量多，所以把中斷處理分成中斷上半部和下半部。上半部：有嚴(yán)格時(shí)限的工作，如：對接收中斷進(jìn)行答復(fù)或復(fù)位；下半部：可以稍后或者說可以延遲一點(diǎn)的工作；中斷處理程序：操作系統(tǒng)在響應(yīng)一個(gè)中斷的時(shí)候，內(nèi)核會執(zhí)行一個(gè)函數(shù)，該函數(shù)，這個(gè)函數(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：中斷處理程序標(biāo)志；如IRQ_DISABLED，IRQ_SHARED等；Name:中斷相關(guān)設(shè)備的名字；Dev_id:用于共享中斷線：注冊、釋放中斷處理程序：驅(qū)動(dòng)處理程序可以通過request_irq()函數(shù)注冊一個(gè)中斷處理程序，并且激活中斷線，以便處理中斷。中斷和中斷處理三、工作隊(duì)列：二、tasklet:中斷下半部實(shí)現(xiàn)機(jī)制：一、軟中斷：中斷和中斷處理軟中斷的實(shí)現(xiàn):軟中斷是在編譯期間靜態(tài)分配的，它由softirq_action的結(jié)構(gòu)表示：structsoftirq_action{void(*action)(structsoftirq_action*);};軟中斷處理程序:軟中斷處理程序action的函數(shù)原型如下：Voidsoftirq_handler(structsoftirq_action*)當(dāng)內(nèi)核運(yùn)行一個(gè)軟中斷處理程序時(shí)，它會執(zhí)行這個(gè)action函數(shù)。

中斷和中斷處理中斷和中斷處理執(zhí)行軟中斷:一個(gè)注冊的軟中斷必須被標(biāo)記后才會執(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——一個(gè)結(jié)束請求的函數(shù)，會觸發(fā)軟中斷；到此中斷上半部結(jié)束；中斷下半部：（軟中斷機(jī)制）blk_done_softirqscsi_softirq_donescsi_finish_commandscsi_io_completionscsi_end_requestblk_end_iobio_endio。中斷和中斷處理工作隊(duì)列：工作隊(duì)列是另一種將工作推后執(zhí)行的形式，它可以把推后執(zhí)行的工作交給一個(gè)內(nèi)核線程來執(zhí)行，也就是用這種機(jī)制實(shí)現(xiàn)中斷下半部的是在進(jìn)程上下文中執(zhí)行的，工作隊(duì)列可以重新調(diào)度甚至睡眠。工作隊(duì)列的實(shí)現(xiàn)：工作隊(duì)列子系統(tǒng)是一個(gè)用于創(chuàng)建內(nèi)核線程的接口，通過它創(chuàng)建的進(jìn)程負(fù)責(zé)由內(nèi)核其他部分排到隊(duì)列里的任務(wù)。它創(chuàng)建內(nèi)核線程稱為工作者線程。工作隊(duì)列線程可以讓你的驅(qū)動(dòng)程序創(chuàng)建一個(gè)專門的工作者線程來處理推后執(zhí)行的工作。同時(shí)也提供一個(gè)缺省的工作者線程來處理這些操作。表示線程的數(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;};中斷和中斷處理使用工作隊(duì)列：一、創(chuàng)建推后執(zhí)行的工作：1、靜態(tài)創(chuàng)建：DECLARE_WORK(name，void

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

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

schedule_work();

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

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

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

下半部

上下文

順序執(zhí)行保障

接口復(fù)雜度

軟中斷

中斷

沒有

復(fù)雜tasklet

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

次之

工作隊(duì)列

進(jìn)程沒有（進(jìn)程一樣）

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