2. 程式人生 > >Linux Kernel 3.10核心原始碼分析--塊裝置層request plug/unplug機制

Linux Kernel 3.10核心原始碼分析--塊裝置層request plug/unplug機制

阿新 • • 發佈：2019-02-16
一、基本原理
Linux塊裝置層使用了plug/unplug(蓄流/洩流)的機制來提升IO吞吐量。基本原理為：當IO請求提交時，不知直接提交給底層驅動，而是先將其放入一個佇列中(相當於水池)，待一定時機或週期後再將該佇列中的請求統一下發。將請求放入佇列的過程即plug(蓄流)過程，統一下發請求的過程即為unplug(洩流)過程。每個請求在佇列中等待的時間不會太長，通常在ms級別。
如此設計，可以增加IO合併和排序的機會，便於提升磁碟訪問效率。

二、plug
1、基本流程
從mapping層提交到塊裝置層的io請求為bio，bio會在塊裝置進行合併，並生成新的request，並經過IO排程(排序和合並)之後下發到底層。下發request時，通過請求佇列的make_request_fn介面，其中實質為將請求放入per task的plug佇列，當佇列滿或在進行排程時(schedule函式中)會根據當前程序的狀態將該佇列中的請求flush到派發佇列中，並觸發unplug(具體流程後面介紹)。

。
per task的plug佇列：新核心版本中實現的機制。IO請求提交時先鏈入此佇列，當該佇列滿時(>BLK_MAX_REQUEST_COUNT)，會flush到相應裝置的請求佇列中(request_queue)。
優點：per task維護plug佇列，可以避免頻繁對裝置的請求佇列操作導致的鎖競爭，能提升效率。

2、plug基本程式碼流程如下：
submit_bio->
    generic_make_request->
        make_request->
            blk_queue_bio->
                list_add_tail(&req->queuelist, &plug->list);//將請求加入plug佇列


三、unplug
unplug分同步unplug和非同步unplug兩種方式。
同步unplug即當即通過呼叫blk_run_queue對下發請求佇列中的情況。
非同步unplug，通過喚醒kblockd工作佇列來對請求佇列中的請求進行下發。

1、kblockd工作佇列的初始化：
1) 分配工作佇列
主要程式碼流程：
blk_dev_init ->
alloc_workqueue //分配工作佇列
2) 初始化工作佇列
blk_alloc_queue_node():

點選(此處)摺疊或開啟

  1. /*在指定node上分配請求佇列*/
  2. struct request_queue *blk_alloc_queue_node(
    gfp_t gfp_mask, int node_id)
  3. {
  4. struct request_queue *q;
  5. int err;
  6. /*分配請求佇列需要的記憶體，從slab中分配，並初始化為0*/
  7. q = kmem_cache_alloc_node(blk_requestq_cachep,
  8. gfp_mask | __GFP_ZERO, node_id);
  9. if (!q)
  10. return NULL;
  11. if (percpu_counter_init(&q->mq_usage_counter, 0))
  12. goto fail_q;
  13. q->id = ida_simple_get(&blk_queue_ida, 0, 0, gfp_mask);
  14. if (q->id < 0)
  15. goto fail_c;
  16. q->backing_dev_info.ra_pages =
  17. (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
  18. q->backing_dev_info.state = 0;
  19. q->backing_dev_info.capabilities = BDI_CAP_MAP_COPY;
  20. q->backing_dev_info.name = "block";
  21. q->node = node_id;
  22. err = bdi_init(&q->backing_dev_info);
  23. if (err)
  24. goto fail_id;
  25. /*設定laptop模式下的定時器*/
  26. setup_timer(&q->backing_dev_info.laptop_mode_wb_timer,
  27.    laptop_mode_timer_fn, (unsigned long) q);
  28. /*
  29.  * 關鍵點:設定請求佇列的超時定時器，預設超時時間為30s，當30s內IO請求未完成時，定時器到期，
  30.  * 進行重試或錯誤處理。這是IO 錯誤處理架構中的關鍵點之一，在核心老版本中(2.6.38?)，該定時器
  31.  * 是在scsi中間層定義的，新版本中將其上移至塊裝置層。Fixme:為何要這樣?*/
  32. setup_timer(&q->timeout, blk_rq_timed_out_timer, (unsigned long) q);
  33. /*初始化各個佇列*/
  34. INIT_LIST_HEAD(&q->queue_head);
  35. INIT_LIST_HEAD(&q->timeout_list);
  36. INIT_LIST_HEAD(&q->icq_list);
  37. #ifdef CONFIG_BLK_CGROUP
  38. INIT_LIST_HEAD(&q->blkg_list);
  39. #endif
  40. INIT_LIST_HEAD(&q->flush_queue[0]);
  41. INIT_LIST_HEAD(&q->flush_queue[1]);
  42. INIT_LIST_HEAD(&q->flush_data_in_flight);
  43. /*初始化delay_work，用於在kblockd中非同步unplug請求佇列*/
  44. INIT_DELAYED_WORK(&q->delay_work, blk_delay_work);
  45. kobject_init(&q->kobj, &blk_queue_ktype);
  46. mutex_init(&q->sysfs_lock);
  47. spin_lock_init(&q->__queue_lock);
  48. /*
  49. * By default initialize queue_lock to internal lock and driver can
  50. * override it later if need be.
  51. */
  52. q->queue_lock = &q->__queue_lock;
  53. /*
  54. * A queue starts its life with bypass turned on to avoid
  55. * unnecessary bypass on/off overhead and nasty surprises during
  56. * init. The initial bypass will be finished when the queue is
  57. * registered by blk_register_queue().
  58. */
  59. q->bypass_depth = 1;
  60. __set_bit(QUEUE_FLAG_BYPASS, &q->queue_flags);
  61. init_waitqueue_head(&q->mq_freeze_wq);
  62. if (blkcg_init_queue(q))
  63. goto fail_id;
  64. return q;
  65. fail_id:
  66. ida_simple_remove(&blk_queue_ida, q->id);
  67. fail_c:
  68. percpu_counter_destroy(&q->mq_usage_counter);
  69. fail_q:
  70. kmem_cache_free(blk_requestq_cachep, q);
  71. return NULL;
  72. }
2) kblockd工作佇列的工作內容
kblockd工作佇列的工作內容有由blk_delay_work()函式實現，主要就是調用__blk_run_queue進行unplug請求佇列。

點選(此處)摺疊或開啟

  1. /*IO請求佇列的delay_work，用於在kblockd中非同步unplug請求佇列*/
  2. static void blk_delay_work(struct work_struct *work)
  3. {
  4. struct request_queue *q;
  5. /*獲取delay_work所在的請求佇列*/
  6. q = container_of(work, struct request_queue, delay_work.work);
  7. spin_lock_irq(q->queue_lock);
  8. /*直接run queue，最終呼叫request_fn對佇列中的請求逐一處理*/
  9. __blk_run_queue(q);
  10. spin_unlock_irq(q->queue_lock);
  11. }

2、unplug機制
核心中設計了兩種unplug機制：
1）排程時進行unplug(非同步方式)
當發生核心排程時，當前程序sleep前，先將當前task的plug列表中的請求flush到派發佇列中，並進行unplug。
主要程式碼流程如下：
schedule->
    sched_submit_work ->
        blk_schedule_flush_plug()->
            blk_flush_plug_list(plug, true) ->注意:這裡傳入的from_schedule引數為true，表示將觸發非同步unplug，即喚醒kblockd工作佇列來進行unplug操作。後續的kblockd的喚醒週期在塊裝置驅動中設定，比如scsi中設定為3ms。
                queue_unplugged->
                    blk_run_queue_async

queue_unplugged():

點選(此處)摺疊或開啟

  1. /*unplug請求佇列，plug相當於蓄水，將請求放入池子(請求佇列)中，unplug相當於放水，即開始呼叫請求佇列的request_fn(scsi_request_fn)來處理請求佇列中的請求，將請求提交到scsi層(塊裝置驅動層)*/
  2. static void queue_unplugged(struct request_queue *q, unsigned int depth,
  3.    bool from_schedule)
  4. __releases(q->queue_lock)
  5. {
  6. trace_block_unplug(q, depth, !from_schedule);
  7. /*呼叫塊裝置驅動層提供的request_fn介面處理請求佇列中的請求，分非同步和同步兩種情況。*/
  8. if (from_schedule)
  9. /*非同步unplug，即通過kblockd工作佇列來處理，該工作佇列定期喚醒(5s)，通過這種方式可以控制流量，提高吞吐量*/
  10. blk_run_queue_async(q);
  11. else
  12. /*同步unplug，即直接呼叫裝置驅動層提供的request_fn介面處理請求佇列中的請求*/
  13. __blk_run_queue(q);
  14. spin_unlock(q->queue_lock);
  15. }

blk_run_queue_async():

點選(此處)摺疊或開啟

  1. /*非同步unplug，即通過kblockd工作佇列來處理，該工作佇列定期喚醒(5s)，通過這種方式可以控制流量，提高吞吐量*/
  2. void blk_run_queue_async(struct request_queue *q)
  3. {
  4. if (likely(!blk_queue_stopped(q) && !blk_queue_dead(q)))
  5. /*喚醒kblockd相關的工作佇列，進行unplug處理，注意:這裡的delay傳入0表示立刻喚醒，kblockd對應的處理介面為:blk_delay_work*/
  6. mod_delayed_work(kblockd_workqueue, &q->delay_work, 0);
  7. }

scsi_request_fn()://scsi塊裝置驅動的request_fn()介面，其中當scsi命令下發失敗時，會重設kblockd，延遲unplug請求佇列。

點選(此處)摺疊或開啟

  1. static void scsi_request_fn(struct request_queue *q)
  2. {
  3. ...
  4. /*
  5. * Dispatch the command to the low-level driver.
  6. */
  7. /*將scsi命令下發到底層驅動，當返回非0時，表示命令下發失敗，則當前的請求佇列需要被plug*/
  8. rtn = scsi_dispatch_cmd(cmd);
  9. spin_lock_irq(q->queue_lock);
  10. /*命令下發失敗，需要plug請求佇列*/
  11. if (rtn)
  12. goto out_delay
  13. ...
  14. out_delay:
  15. if (sdev->device_busy == 0)
  16. /*命令下發失敗，需要延遲處理，需plug請求佇列，設定3ms定時啟動kblockd工作佇列，進行請求佇列的unplug*/
  17. blk_delay_queue(q, SCSI_QUEUE_DELAY);
  18. blk_delay_queue
  19. /*在指定msecs時間後啟動kblockd工作佇列*/
  20. void blk_delay_queue(struct request_queue *q, unsigned long msecs)
  21. {
  22. if (likely(!blk_queue_dead(q)))
  23. queue_delayed_work(kblockd_workqueue, &q->delay_work,
  24.   msecs_to_jiffies(msecs));
  25. }

2）提交IO請求時(make_request)進行unplug
提交IO請求時(make_request)，先將請求提交時先鏈入此佇列，當該佇列滿時(>BLK_MAX_REQUEST_COUNT)，會flush到相應裝置的請求佇列中(request_queue)。
主要程式碼流程為：
submit_bio->
    generic_make_request->
        make_request->
            blk_queue_bio->
                blk_flush_plug_list(plug, false) ->注意:這裡傳入的from_schedule引數為false，表示將觸發同步unplug，即當即下發請求。
                    queue_unplugged->
                        blk_run_queue_async ->
                            __blk_run_queue

普通塊裝置的make_request介面在3.10核心版本中被設定為blk_queue_bio，相應程式碼分析如下：

點選(此處)摺疊或開啟

  1. /*在submit_bio中被呼叫，用於合併bio，並提交請求(request)，請求提交到per task的plug list中*/
  2. void blk_queue_bio(struct request_queue *q, struct bio *bio)
  3. {
  4.     const bool sync = !!(bio->bi_rw & REQ_SYNC);
  5.     struct blk_plug *plug;
  6.     int el_ret, rw_flags, where = ELEVATOR_INSERT_SORT;
  7.     struct request *req;
  8.     unsigned int request_count = 0;
  9.     /*
  10.      * low level driver can indicate that it wants pages above a
  11.      * certain limit bounced to low memory (ie for highmem, or even
  12.      * ISA dma in theory)
  13.      */
  14.     /*bounce buffer(回彈緩衝區)使用*/
  15.     blk_queue_bounce(q, &bio);
  16.     if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
  17.         bio_endio(bio, -EIO);
  18.         return;
  19.     }
  20.     if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) {
  21.         spin_lock_irq(q->queue_lock);
  22.         where = ELEVATOR_INSERT_FLUSH;
  23.         goto get_rq;
  24.     }
  25.     /*
  26.      * Check if we can merge with the plugged list before grabbing
  27.      * any locks.
  28.      */
  29.     /*嘗試將bio合併到request中*/
  30.     if (blk_attempt_plug_merge(q, bio, &request_count))
  31.         return;
  32.     spin_lock_irq(q->queue_lock);
  33.     el_ret = elv_merge(q, &req, bio);
  34.     /*向後合併*/
  35.     if (el_ret == ELEVATOR_BACK_MERGE) {
  36.         if (bio_attempt_back_merge(q, req, bio)) {
  37.             elv_bio_merged(q, req, bio);
  38.             if (!attempt_back_merge(q, req))
  39.                 elv_merged_request(q, req, el_ret);
  40.             goto out_unlock;
  41.         }
  42.     /*向前合併*/
  43.     } else if (el_ret == ELEVATOR_FRONT_MERGE) {
  44.         if (bio_attempt_front_merge(q, req, bio)) {
  45.             elv_bio_merged(q, req, bio);
  46.             if (!attempt_front_merge(q, req))
  47.                 elv_merged_request(q, req, el_ret);
  48.             goto out_unlock;
  49.         }
  50.     }
  51. /*不能合併，需要新建request來處理bio*/
  52. get_rq:
  53.     /*
  54.      * This sync check and mask will be re-done in init_request_from_bio(),
  55.      * but we need to set it earlier to expose the sync flag to the
  56.      * rq allocator and io schedulers.
  57.      */
  58.     rw_flags = bio_data_dir(bio);
  59.     /*判斷是否需要sync，即直接將IO請求unplug(提交到塊裝置驅動層)，不用等待kblockd來定期plug*/
  60.     if (sync)
  61.         rw_flags |= REQ_SYNC;
  62.     /*
  63.      * Grab a free request. This is might sleep but can not fail.
  64.      * Returns with the queue unlocked.
  65.      */
  66.     /*從請求佇列中取一個request*/
  67.     req = get_request(q, rw_flags, bio, GFP_NOIO);
  68.     if (unlikely(!req)) {
  69.         bio_endio(bio, -ENODEV);    /* @q is dead */
  70.         goto out_unlock;
  71.     }
  72.     /*
  73.      * After dropping the lock and possibly sleeping here, our request
  74.      * may now be mergeable after it had proven unmergeable (above).
  75.      * We don't worry about that case for efficiency. It won't happen
  76.      * often, and the elevators are able to handle it.
  77.      */
  78.     /*將bio加入新的request中*/
  79.     init_request_from_bio(req, bio);
  80.     if (test_bit(QUEUE_FLAG_SAME_COMP, &q->queue_flags))
  81.         req->cpu = raw_smp_processor_id();
  82.     plug = current->plug;
  83.     /*如果有plug，則將請求加入到plug的list中，如果沒有則直接呼叫__blk_run_queue提交請求*/
  84.     if (plug) {
  85.         /*
  86.          * If this is the first request added after a plug, fire
  87.          * of a plug trace. If others have been added before, check
  88.          * if we have multiple devices in this plug. If so, make a
  89.          * note to sort the list before dispatch.
  90.          */
  91.         if (list_empty(&plug->list))
  92.             trace_block_plug(q);
  93.         else {/*如果請求佇列中的請求數超過了限值，則先unplug?*/
  94.             if (request_count >= BLK_MAX_REQUEST_COUNT) {
  95.                 blk_flush_plug_list(plug, false);
  96.                 trace_block_plug(q);
  97.             }
  98.         }
  99.         /*把請求加入到plug的list中，當plug的list滿了後(>BLK_MAX_REQUEST_COUNT)，會flush到相應裝置的請求佇列中(request_queue)*/
  100.         list_add_tail(&req->queuelist, &plug->list);
  101.         blk_account_io_start(req, true);
  102.     } else {
  103.         spin_lock_irq(q->queue_lock);
  104.         add_acct_request(q, req, where);
  105.         /*如果沒有plug控制，最終呼叫此介面處理佇列中的請求，最終會呼叫請求佇列的request_fn介面處理請求*/
  106.         __blk_run_queue(q);
  107. out_unlock:
  108.         spin_unlock_irq(q->queue_lock);
  109.     }
  110. }

原文地址： http://blog.chinaunix.net/uid-14528823-id-4778396.html

相關推薦

Linux Kernel 3.10核心原始碼分析--塊裝置層request plug/unplug機制

一、基本原理Linux塊裝置層使用了plug/unplug(蓄流/洩流)的機制來提升IO吞吐量。基本原理為：當IO請求提交時，不知直接提交給底層驅動，而是先將其放入一個佇列中(相當於水池)，待一定時機或週期後再將該佇列中的請求統一下發。將請求放入佇列的過程即plug(蓄流)

Linux kernel 3.10 sg 驅動分析

原始碼地址 主裝置號 #define SCSI_GENERIC_MAJOR 21 file operations 此結構定義了sg的read write ioctl的具體實現 s

ernel 3.10核心原始碼分析--KVM相關--虛擬機器執行

1、基本原理 KVM虛擬機器通過字元裝置/dev/kvm的ioctl介面建立和執行，相關原理見之前的文章說明。 虛擬機器的執行通過/dev/kvm裝置ioctl VCPU介面的KVM_RUN指令實現，在VM和VCPU建立好並完成初始化後，就可以排程該虛擬機器運行了，通

Linux核心原始碼分析--zImage出生實錄（Linux-3.0 ARMv7）

此文為兩年前為好友劉慶敏的書《嵌入式Linux開發詳解--基於AT91RM9200和Linux 2.6》中幫忙寫的章節的重新整理。如有雷同，純屬必然。經作者同意，將我寫的部分重新整理後放入blog中。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mmap核心原始碼分析，基於核心版本3.10（三）

之前寫了（一）（二）其實就梳理到了get_unmapped_area的內容，而且有一點混亂，這裡進行第三篇的講解，講解在do_mmap_pgoff中除了get_unmapped_area的內容，來了解mmap的具體實現。通過（一）（二）（三）來將mmap核心原始碼進行一次梳理

塊IO層（Linux核心原始碼分析）

背景 本篇部落格重點分析塊IO層，試圖瞭解在linux原始碼中是如何實現塊IO的。 基本知識 塊裝置與字元裝置 塊裝置與字元裝置都是物理外設。簡單來說，塊裝置與字元裝置的最大區別在於塊裝置都隨機對資料片段進行讀寫的，而字元裝置都以順序對資料片段進

linux核心原始碼分析-夥伴系統

之前的文章已經介紹了夥伴系統，這篇我們主要看看原始碼中是如何初始化夥伴系統、從夥伴系統中分配頁框，返回頁框於夥伴系統中的。 　　我們知道，每個管理區都有自己的夥伴系統管理屬於這個管理區的頁框，這也說明了，在夥伴系統初始化時，管理區必須要已經存在(初始化完成)

Linux Block Layer塊裝置層基於MultiQueue的部分原始碼分析

本文主要分析基於MultiQueue的Linux Block Layer層部分原始碼內容 ！！！為幫助理解，提供了一份整體流程圖如下（內容太大模糊了），細緻的visio以及pdf版本可在本人的下載資源中下載，地址：http://download.csdn.ne

Linux系統啟動那些事—基於Linux 3.10核心

對於嵌入式平臺ARM平臺，說說其NANDFlash的啟動過程，請先看圖2.2描述的NAND flash中的程式佈局，上電時，首先cpu會自動將自動從NAND flash中拷貝一定程式碼到記憶體中執行，這是任何支援nand方式啟動必須支援的，一般我見到的有2K還有4K的，這部分的程式碼我們將其稱為boots

linux核心原始碼分析

本文基於3.18.3核心的分析,nvme裝置為pcie介面的ssd,其驅動名稱為nvme.ko,驅動程式碼在drivers/block/nvme-core.c. 驅動的載入 　　驅動載入實際就是module的載入,而module載入時會對整個module進行初始化,nvme驅動的module初始化函式

s3c2410 RTC驅動框架linux核心原始碼分析

實在無聊中就將原來的一些東西整理了一下，自己是個記性不好的人，隔斷時間整理自己，同時也希望可以方便他人。 -------------------------------------------------------------------------------------

Linux核心原始碼分析——Linux核心的入口

Jack：hi，淫龍，在Linux核心的原始碼裡，有幾段彙編程式碼，那幾段程式碼是負責Linux核心引導的。 我：是的。早期的Linux核心引導程式碼只有bootsect.s、setup.s、head.s這3個檔案，這三個檔案都是Linus在1991年左右親手寫的。後來的程

Linux核心原始碼分析--記憶體管理（一、分頁機制）

        Linux系統中分為幾大模組：程序排程、記憶體管理、程序通訊、檔案系統、網路模組；各個模組之間都有一定的聯絡，就像蜘蛛網一樣，所以這也是為什麼Linux核心那麼難理解，因為不知道從哪裡開始著手去學習。很多人會跟著系統上電啟動 BIOS-->bootse

Linux 3.0核心Makefile分析

[摘要] 由於Linux的獨特優勢，使越來越多的企業和科研機構把目光轉向Linux的開發和研究上。目前Linux最新的穩定核心版本為2.6.17，但是當今絕大部分對於Linux Makefile的介紹文章都是基於2.4核心的，可以說關於2.6核心Makefile相

Linux核心原始碼分析--檔案系統（五、Inode.c）

_bmap()         1、_bmap()函式用於把一個檔案資料塊對映到盤塊的處理操作                  因為一個i節點對應一個檔案，所以上面的i節點對映的邏輯塊號就是檔案資料存放的邏輯塊號；i_zone[0]到i_zone[6]是直接邏輯塊號，i

Linux-0.11核心原始碼分析系列：記憶體管理get_free_page()函式分析

Linux-0.11記憶體管理模組是原始碼中比較難以理解的部分，現在把筆者個人的理解發表 先發Linux-0.11核心記憶體管理get_free_page()函式分析有時間再寫其他函式或者檔案的:) /*  *Author  : DavidLin  *Date    :

ARMv8 Linux核心原始碼分析：__flush_dcache_all()

1.1   /* *  Flush the wholeD-cache.  * Corrupted registers: x0-x7, x9-x11  */ ENTRY(__flush_dcache_all) //保證之前的訪存指令的順序     dsb sy      

記憶體管理（Linux核心原始碼分析）

背景 本篇部落格試圖通過linux核心原始碼分析linux的記憶體管理機制，並且對比核心提供的幾個分配記憶體的介面函式。然後聊下slab層的用法以及介面函式。 核心分配記憶體與使用者態分配記憶體 核心分配記憶體與使用者態分配記憶體顯然是不同的，核心不可

Linux核心原始碼分析--記憶體管理（二、函式實現技巧）

        仔細的分析了一下各個記憶體管理函式的實現，發現裡面涉及到了幾個技巧，如果知道了這幾個技巧，那麼閱讀記憶體管理原始碼將會事半功倍（主要是這幾個技巧在幾個函式中都出現過），當然也會選擇性的分析幾個比較重要的函式實現； 函式實現技巧         1、向上取整

Linux核心原始碼分析--系統時間初始化（kernel_mktime()函式）

        從boot檔案中的幾個彙編程式執行後跳轉到init檔案中的main.c程式開始繼續執行，該main.c函式式為系統執行的環境進行初始化的。首先來看系統時間的初始化（因為系統時間的初始化開始程式就在init檔案中），其中主要還是由kernel中的mktime.