剛提交了一篇《內核block層IO調度器—bfq算法之深入探索1》，較為深入的介紹了一些bfq算法的知識點，本文再繼續介紹一下bfq算法的其他知識點：主要講解bfq_bfqq_has_short_ttime、bfq_bfqq_IO_bound、bfq_bfqq_in_large_burst 、bfq_better_to_idle、bfqq->wr_coeff有關的bfqq權重提升。
在看本文前，希望讀者先看下我之前寫的幾篇介紹bfq算法的文章，打個基礎。本文基于centos 8.3，內核版本4.18.0-240.el8，詳細源碼注釋見 https://github.com/dongzhiyan-stack/linux-4.18.0-240.el8。
1：bfq_better_to_idle函數源碼講解
bfq_better_to_idle()函數多處都有調用，比如：
static bool bfq_bfqq_must_idle(struct bfq_queue *bfqq){??? return RB_EMPTY_ROOT(&bfqq->sort_list) && bfq_better_to_idle(bfqq);}static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd){??? .........??? if (bfqd->in_service_queue == bfqq) {??????? //bfqq上沒有IO請求但是可能很快就有新的IO請求來，bfqq還不能過期失效，而是啟動 idle timer定時器??????? if (bfq_bfqq_must_idle(bfqq)) {??????????? if (bfqq->dispatched == 0)??????????????? bfq_arm_slice_timer(bfqd);??????? }??? }??? .........}
這個場景是說：bfqq上沒有要派發的IO請求了，但有較大概率bfqq綁定的進程很快還有新的IO請求要來，故bfqq還不能立即過期失效，而是進入idle狀態，啟動idle timer定時器等待可能馬上來的新的IO請求。怎么判定bfqq綁定的進程可以進入idle狀態而等待新的IO請求來呢？就是靠bfq_better_to_idle()函數返回true，看下它的源碼：
static bool bfq_better_to_idle(struct bfq_queue *bfqq){??? struct bfq_data *bfqd = bfqq->bfqd;??? bool idling_boosts_thr_with_no_issue, idling_needed_for_service_guar;??? ...............??? //異步bfqq或者idle調度算法的bfqq直接返回false??? if (bfqd->bfq_slice_idle == 0 || !bfq_bfqq_sync(bfqq) ||?????? bfq_class_idle(bfqq))??????? return false;??? //bfqd沒有一個bfqq的權重提升了并且當前的bfqq綁定的進程向bfqq插入IO請求很快，則idling_boosts_thr_with_no_issue是true??? idling_boosts_thr_with_no_issue =?????? ?idling_boosts_thr_without_issues(bfqd, bfqq);??? //當前的bfqq權重提升了并且正在磁盤驅動層傳輸的IO請求比較多等等則返回true??? idling_needed_for_service_guar =??????? idling_needed_for_service_guarantees(bfqd, bfqq);??? return idling_boosts_thr_with_no_issue ||??????? idling_needed_for_service_guar;}
可以發現主要是調用idling_boosts_thr_without_issues()和idling_needed_for_service_guarantees()兩個函數，如果二者的返回值有一個是true，則bfq_better_to_idle()函數就返回true。簡單總結，有以下兩個條件有一個成立則bfq_better_to_idle()返回true ：
1:bfqd沒有一個bfqq的權重提升了并且當前的bfqq綁定的進程有頻繁向bfqq的隊列插入IO請求的特性。??
2:當前的bfqq權重提升了并且正在磁盤驅動層傳輸的IO請求比較多等等則返回true 。簡單說，當前的bfqq還不能過期失效，有較大概率bfqq綁定的進程很快還有IO要傳輸。
下邊重點看下idling_boosts_thr_without_issues()和idling_needed_for_service_guarantees()兩個函數。
//bfqd沒有一個bfqq的權重提升了并且當前的bfqq綁定的進程有頻繁向bfqq的隊列插入IO請求的特性，該函數返回truestatic bool idling_boosts_thr_without_issues(struct bfq_data *bfqd,???????????????????????? struct bfq_queue *bfqq){??? //用的是SATA盤并且bfq總的已派發但還沒完成的IO請求數很少，則rot_without_queueing為true??? bool rot_without_queueing =??????? !blk_queue_nonrot(bfqd->queue) && !bfqd->hw_tag,??????? bfqq_sequential_and_IO_bound,??????? idling_boosts_thr;??? /* No point in idling for bfqq if it won't get requests any longer */??? if (unlikely(!bfqq_process_refs(bfqq)))??????? return false;??? //就是說，bfqq綁定的進程需要大量連續快速傳輸IO請求??? bfqq_sequential_and_IO_bound = !BFQQ_SEEKY(bfqq) &&??????? bfq_bfqq_IO_bound(bfqq) && bfq_bfqq_has_short_ttime(bfqq);/*idling_boosts_thr 為true，有兩種情況。1:用的是SATA盤并且bfq總的已派發但還沒完成的IO請求數很少 2:bfqq綁定的進程需要大量連續快速傳輸IO請求，并且用的SATA盤(或者IO請求在磁盤驅動傳輸的比較慢)*/??? idling_boosts_thr = rot_without_queueing || ??? //是SATA盤 或者 bfq總的已派發但還沒完成的IO請求數比較多，說明IO在磁盤驅動傳輸的很慢??????? ((!blk_queue_nonrot(bfqd->queue) || !bfqd->hw_tag) &&? ? ? ? ? ? ??//bfqq綁定的進程需要大量連續快速傳輸IO請求? ? ? ? ? ? ? bfqq_sequential_and_IO_bound);??? //idling_boosts_thr為true，并且沒有bfqq的權重提升了則返回true??? return idling_boosts_thr && bfqd->wr_busy_queues == 0;}
首先是bfqq_sequential_and_IO_bound = !BFQQ_SEEKY(bfqq) &&bfq_bfqq_IO_bound(bfqq) && bfq_bfqq_has_short_ttime(bfqq)。
1: !BFQQ_SEEKY(bfqq)為true表示bfqq派發的隨機IO請求不多(磁盤是SATA)，或者bfqq派發的每個IO請求傳輸的數據量不多(磁盤是ssd)。關于BFQQ_SEEKY()的理解，會在本文最后一節詳細介紹。
2: bfq_bfqq_IO_bound 表示bfqq大量派發IO請求標記，如果bfqq沒有大量派發IO請求而消耗完配額，就會清理掉bfq_bfqq_IO_bound標記
3: bfq_bfqq_has_short_ttime ：bfqq有bfq_bfqq_has_short_ttime標記，說明進程向bfqq->sort_list插入IO請求很快。有可能bfq_better_to_idle()->idling_boosts_thr_without_issues()返回true。這樣的話，IO請求傳輸完成執行到bfq_completed_request()，因為bfq_better_to_idle()返回true，并且bfqq派發的IO請求都傳輸完了(bfqq->dispatched 是0)，則啟動idle timer。先不讓bfqq過期失效，而是等一小段時間，看bfqq是否會來新的IO請求，沒有的話再令bfqq過期失效。
bfq_bfqq_IO_bound(bfqq) 和bfq_bfqq_has_short_ttime(bfqq)兩個宏定義的作用，本文最后會重點講解。
接著是idling_boosts_thr = rot_without_queueing || ((!blk_queue_nonrot(bfqd->queue) || !bfqd->hw_tag) && bfqq_sequential_and_IO_bound)。源碼里說的比較清楚，這里再貼下：idling_boosts_thr 為true，有兩種情況。1:用的是SATA盤并且bfq總的已派發但還沒完成的IO請求數很少 2:bfqq綁定的進程需要大量連續快速傳輸IO請求，并且用的SATA盤(或者IO請求在磁盤驅動傳輸的比較慢)。
最后，只要idling_boosts_thr是true并且沒有bfqq的權重提升了，則idling_boosts_thr_without_issues()返回true。我簡單總結下：bfqd沒有一個bfqq的權重提升了并且當前的bfqq綁定的進程有頻繁向bfqq的隊列插入IO請求的特性，則idling_boosts_thr_without_issues()返回true。
接著看下bfq_better_to_idle()里調用的idling_needed_for_service_guarantees()函數，
static bool idling_needed_for_service_guarantees(struct bfq_data *bfqd,???????????????????????? struct bfq_queue *bfqq){??? /* No point in idling for bfqq if it won't get requests any longer */??? if (unlikely(!bfqq_process_refs(bfqq)))??????? return false;??? //bfqq權重提升了并且 權重提升的bfqq數量比在st->active tree的bfqq的數量少(或者bfq在磁盤驅動傳輸的IO請求個數很多)??? return (bfqq->wr_coeff > 1 &&???????????? (bfqd->wr_busy_queues < bfq_tot_busy_queues(bfqd) || bfqd->rq_in_driver >= bfqq->dispatched + 4)??????????? ) ||?????????? bfq_asymmetric_scenario(bfqd, bfqq);//????這個不知道啥用}
idling_needed_for_service_guarantees()作用，我的簡單總結是：當前的bfqq權重提升了并且正在磁盤驅動層傳輸的IO請求比較多等等則返回true。
2：bfqq->wr_coeff與進程權重提升
進程的權重是靠bfqq的entity->weight變量體現，而entity->weight=默認權重*bfqq->wr_coeff。bfqq->wr_coeff是權重系數，默認是1，就是說默認情況進程不會提升權重。進程提升權重的過程是什么？首先要增大bfqq->wr_coeff，這個函數過程是：__bfq_insert_request()->bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()函數，在bfq_update_bfqq_wr_on_rq_arrival()函數會增大bfqq->wr_coeff。什么情況下會執行這個函數過程呢？
1：進程第一次傳輸IO請求，分配了新的bfqq，向bfqq算法隊列添加IO請求。執行到__bfq_insert_request()->bfq_add_request()，if (!bfq_bfqq_busy(bfqq))成立，則執行bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()，但是分析不符合bfqq->wr_coeff增大條件，就是說bfq_update_bfqq_wr_on_rq_arrival()里不會增大bfqq->wr_coeff。
2：bfqq原本是idle狀態(因為bfqq過期失效而處于st->idle tree)。現在bfqq又來了新的IO請求，要激活bfqq，并且bfqq的entity從st->idle tree移動到st->active tree。此時執行到__bfq_insert_request()->bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()函數，有較大概率增大bfqq->wr_coeff。
然后，把bfqq的entity移動到st->active tree，函數流程是：bfq_bfqq_handle_idle_busy_switch()->bfq_add_bfqq_busy->bfq_activate_bfqq->bfq_activate_requeue_entity->__bfq_activate_requeue_entity->__bfq_activate_entity->bfq_update_fin_time_enqueue->__bfq_entity_update_weight_prio()函數。在__bfq_entity_update_weight_prio()中執行形如entity->weight = 默認權重 *bfqq->wr_coeff，真正增大進程的權重。
下邊詳細說說bfqq->wr_coeff與進程權重提升相關函數源碼，先看下bfq_add_request()函數。
static void bfq_add_request(struct request *rq){??? //通過rq->elv.priv[1]得到保存的bfqq??? struct bfq_queue *bfqq = RQ_BFQQ(rq);??? struct bfq_data *bfqd = bfqq->bfqd;??? struct request *next_rq, *prev;??? unsigned int old_wr_coeff = bfqq->wr_coeff;??? bool interactive = false;??? ...........??? //bfq_add_request()中把IO請求添加到bfqq->sort_list鏈表??? elv_rb_add(&bfqq->sort_list, rq);??? ...........??? //bfqq是新創建的或者bfqq在st->idle tree該if才成立??? if (!bfq_bfqq_busy(bfqq))//激活bfqq，把bfqq添加到st->active tree??????? bfq_bfqq_handle_idle_busy_switch(bfqd, bfqq, old_wr_coeff,???????????????????????? rq, &interactive);??? else {??????? if (bfqd->low_latency && old_wr_coeff == 1 && !rq_is_sync(rq) &&??????????? time_is_before_jiffies(??????????????? bfqq->last_wr_start_finish +??????????????? bfqd->bfq_wr_min_inter_arr_async)) {//測試這里基本沒成立過??????????? //更新bfqq->wr_coeff??????????? bfqq->wr_coeff = bfqd->bfq_wr_coeff;??????????? bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);??????????? bfqd->wr_busy_queues++;??????????? bfqq->entity.prio_changed = 1;??????? }??????? //bfqq->next_rq發生了變化，執行bfq_updated_next_req()根據新的bfqq->next_rq消耗的配額和bfqq->max_budget更新bfqq權重??????? if (prev != bfqq->next_rq)? ? ? ? ? ? ? bfq_updated_next_req(bfqd, bfqq);??? }??? /*這個if很容易成立。bfqd->low_latency默認是1，其他條件只要bfqq老的 bfqq->wr_coeff是1 或者 新的bfqq->wr_coeff是1 或者 bfqq是交互式IO，這個if就會成立。除非bfqq老的bfqq->wr_coeff大于1，并且bfqq是實時性IO(這樣新的bfqq->wr_coeff不是1，并且interactive是0)，if才不會成立。*/??? if (bfqd->low_latency &&??????? (old_wr_coeff == 1 || bfqq->wr_coeff == 1 || interactive))? ? ? ? ? ? ? ? bfqq->last_wr_start_finish = jiffies;}
bfq_add_request()函數一般是把IO請求添加到bfqq->sort_list鏈表，可能會激活bfqq而把bfqq的entity添加到st->active tree，重點是執行bfq_bfqq_handle_idle_busy_switch()，這個函數下邊有講解。該函數最后if (bfqd->low_latency && (old_wr_coeff == 1 || bfqq->wr_coeff == 1 || interactive))里還會更新bfqq->last_wr_start_finish，bfqq->last_wr_start_finish表示bfqq的權重提升時間或者權重結束時間。這個if判斷挺復雜的，bfqd->low_latency默認是1，那什么情況下該if會成立呢？
1:bfqq的bfqq->wr_coeff一直是1，那每次向bfqq插入一個IO請求就bfqq->last_wr_start_finish=jiffies，bfqq->last_wr_start_finish此時記錄的是每次向bfqq插入IO請求的時間點。
2:bfqq的bfqq->wr_coeff是1，但是在上邊的bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()函數里，把bfqq->wr_coeff增大到30或更大，此時bfqq->last_wr_start_finish = jiffies記錄的是bfqq權重提升開始時間。
3:bfqq的權重已經提升了，bfqq->wr_coeff已經大于1，但是bfqq是交互式IO特性，interactive是1，此時也bfqq->last_wr_start_finish = jiffies，此時記錄的是每次向bfqq插入IO請求的時間點。
最后，在派發IO請求時，bfq_dispatch_rq_from_bfqq()->bfq_update_wr_data->bfq_bfqq_end_wr() 在bfqq權重提升結束時也會執行bfqq->last_wr_start_finish = jiffies，此時bfqq->last_wr_start_finish記錄的是權重更新結束時間。
下邊重點講解bfq_bfqq_handle_idle_busy_switch()函數，它里邊根據進程的IO特性增大bfqq->wr_coeff，之后才會增大進程的權重。
2.1 burst型IO、實時性IO、交互式IO
在講解bfq_bfqq_handle_idle_busy_switch()前，有必要說下bfq算法里出現的幾種進程IO特性：burst型IO、實時性IO、交互式IO。burst型IO的進程是默認的，bfq_bfqq_in_large_burst(bfqq)為true就說明bfqq綁定的進程是burst型IO，burst型IO的進程是一段時間內大量傳輸IO請求，是低延遲應該沒什么要求。
交互式IO的進程需要短時間內快速傳輸IO請求，要求低延時。實時性IO的進程，我的理解是需要連續的短時間大量派發IO請求，并且要求低延遲。交互式IO和實時性IO有什么區別？我的理解是，交互式IO的進程只會偶爾短時間快速派發IO請求，比如vim查看一個文件，一次要讀取的數據量不會太大，但是要求快速的讀取文件數據并且顯示出來，低延時；實時性IO的進程，比如音視頻類應用，需要一段時間內連續快速讀取音視頻文件進行解碼，對延遲很敏感。
交互式IO和實時性IO都要求低延遲，都會先增大bfqq->wr_coeff權重系數。然后執行到bfq_update_fin_time_enqueue()時把bfqq的entity插入st->active tree時，先執行__bfq_entity_update_weight_prio()里的entity->weight = 默認權重*bfqq->wr_coeff，增大權重。接著執行bfq_calc_finish(entity, entity->budget)，因為entity->weight很大，計算出來的entity->finish很小，這樣就可以把entity盡可能靠左插入st->active tree。從而保證該entity盡可能早的被bfq調度器用到，接著派發entity對應的bfqq的IO請求。
饒了一大圈，先有增大bfqq->wr_coeff權重系數，接著根據bfqq->wr_coeff計算得到更大的entity->weight權重，entity->weight很大又保證entity更靠左的插入st->active tree，這樣保證entity更早被bfq調度器調度用到。進而很快派發該entity對應bfqq上的IO請求，這應該是交互式IO和實時性IO因bfqq->wr_coeff增大后，可以保證IO低延時的原因的吧。
注意，進程IO特性：burst型IO、實時性IO、交互式IO，本文也有幾處說burst型IO的bfqq，實時性IO的bfqq、交互式IO的bfqq。每一個進程都綁定了一個唯一bfqq，進程和bfqq是一回事。怎么計算進程是burst型IO？實時性IO？交互式IO？重點在bfq_bfqq_handle_idle_busy_switch()函數。
static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,???????????????????????? struct bfq_queue *bfqq,???????????????????????? int old_wr_coeff,???????????????????????? struct request *rq,???????????????????????? bool *interactive){??? bool soft_rt, in_burst, wr_or_deserves_wr,??????? bfqq_wants_to_preempt,??????? //bfqq處于st->idle tree已經很長時間??????? idle_for_long_time = bfq_bfqq_idle_for_long_time(bfqd, bfqq),??? //bfqq在傳輸完最后一個IO請求后的bfqd->bfq_slice_idle * 3時間內又來新的IO請求則arrived_in_time為true??? arrived_in_time =? ktime_get_ns() <=??????????? bfqq->ttime.last_end_request +??????????? bfqd->bfq_slice_idle * 3;??? //bfqq有bfq_bfqq_in_large_burst標記則in_burst為true,in_burst表示bfqq綁定的進程有一段時間內大量派發IO請求的特性??? in_burst = bfq_bfqq_in_large_burst(bfqq);??? //soft_rt為true表示bfqq綁定的進程是實時性IO?? ?soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&??????? !BFQQ_TOTALLY_SEEKY(bfqq) &&??????? !in_burst &&??????? time_is_before_jiffies(bfqq->soft_rt_next_start) &&??????? bfqq->dispatched == 0;??? /*bfqq沒有bfq_bfqq_in_large_burst標記，并且bfqq處于st->idle tree很長時間則interactive是1，這表示bfqq綁定的進程是交互式IO，這種進程一次性派發的IO不多，但是要求低延遲。下邊執行bfq_update_bfqq_wr_on_rq_arrival()令bfqq->wr_coeff=30，將來提升bfqq的權重30倍*/??? *interactive = !in_burst && idle_for_long_time;??? wr_or_deserves_wr = bfqd->low_latency &&??????? (bfqq->wr_coeff > 1 ||???????? (bfq_bfqq_sync(bfqq) && bfqq->bic && (*interactive || soft_rt)));??? /*如果bfqq有bfqq_non_blocking_wait_rq標記，說明之前bfqq配額足夠但是沒有要派發的IO請求而失效。但是在arrived_in_time時間內該bfqq又來了新的IO請求，于是該函數成立返回true，這樣該bfqq有較大概率搶占bfqd->in_service_queue而盡可能快被調度使用作為新的bfqd->in_service_queue，這樣就可以盡可能塊派發該bfqq上新的IO請求*/??? bfqq_wants_to_preempt =??????? bfq_bfqq_update_budg_for_activation(bfqd, bfqq,??????????????????????????? arrived_in_time);??? /*如果bfqq不是新創建的(就是說是處于st->ilde tree)，同時bfqq空閑了idle_for_long_time很長時間，并且在bfqq最后一個IO請求傳輸完成的時間點bfqq->budget_timeout后，過了10s+ bfqq才來了新的IO請求而激活它，于是清理bfqq_in_large_burst標記。*/??? if (likely(!bfq_bfqq_just_created(bfqq)) &&//bfqq不是新創建的(就是說是處于st->ilde tree)??????? idle_for_long_time &&//bfqq空閑很長時間?//bfqq->budget_timeout + 10s < jiffies，就是說 bfqq->budget_timeout后已經過了10s+??????? time_is_before_jiffies(bfqq->budget_timeout + msecs_to_jiffies(10000))) {??????? //從bfqq->burst_list_node鏈表剔除? ? ? ? ? ? hlist_del_init(&bfqq->burst_list_node);? ? ? ? ? ??bfq_clear_bfqq_in_large_burst(bfqq);??? }??? bfq_clear_bfqq_just_created(bfqq);??? //如果bfqq被清理了bfq_bfqq_IO_bound標記??? if (!bfq_bfqq_IO_bound(bfqq)) {??????? /*bfqq在派發完最后一個IO請求后(被移動到st->idle tree)的bfqd->bfq_slice_idle * 3時間內又來新的IO請求則arrived_in_time為true，這樣bfqq->requests_within_timer就加1。如果這樣連續持續120次，bfqq->requests_within_timer大于120，那就再對bfqq設置bfq_bfqq_IO_bound標記*/??????? if (arrived_in_time) {??????????? bfqq->requests_within_timer++;??????????? //bfqd->bfq_requests_within_timer默認120??????????? if (bfqq->requests_within_timer >=??????????????? bfqd->bfq_requests_within_timer)? ? ? ? ? ? ? ? ? ?bfq_mark_bfqq_IO_bound(bfqq);??????? } else? ? ? ? ? ? ? ? ? bfqq->requests_within_timer = 0;??? }??? if (bfqd->low_latency) {??????? if (unlikely(time_is_after_jiffies(bfqq->split_time)))??????????? /* wraparound */??????????? bfqq->split_time =??????????????? jiffies - bfqd->bfq_wr_min_idle_time - 1;??????? //一般情況bfqq->split_time負無窮大，這個if大部分情況都成立??????? if (time_is_before_jiffies(bfqq->split_time +?????????????????????? bfqd->bfq_wr_min_idle_time)) {//這里成立??????????? //根據進程是IO屬性(burst IO、交互式IO、實時性IO)調整bfqq->wr_coeff ??????????? bfq_update_bfqq_wr_on_rq_arrival(bfqd, bfqq,???????????????????????????? old_wr_coeff,???????????????????????????? wr_or_deserves_wr,???????????????????????????? *interactive,???????????????????????????? in_burst,???????????????????????????? soft_rt);??????????? //如果bfqq->wr_coeff變化了，于是把bfqq->entity.prio_changed置1??????????? if (old_wr_coeff != bfqq->wr_coeff)??????????????? bfqq->entity.prio_changed = 1;??????? }??? }??? bfqq->last_idle_bklogged = jiffies;??? bfqq->service_from_backlogged = 0;??? bfq_clear_bfqq_softrt_update(bfqq);??? //把bfqq插入到st->active tree，根據bfqq->wr_coeff真正增大bfqq的entity權重，標記bfqq busy??? bfq_add_bfqq_busy(bfqd, bfqq);??? /*如果bfqq達到搶占bfqd->in_service_queue的條件，則令bfqd->in_service_queue因BFQQE_PREEMPTED而過期失效。但是并不能保證立即被調度bfqq使用，bfqq只是前邊執行bfq_add_bfqq_busy()加入了st->active tree而已!*/??? if (bfqd->in_service_queue &&??????? ((bfqq_wants_to_preempt &&//bfqq_wants_to_preempt搶占條件是1????????? bfqq->wr_coeff >= bfqd->in_service_queue->wr_coeff) || ???????? bfq_bfqq_higher_class_or_weight(bfqq, bfqd->in_service_queue)) &&??????? next_queue_may_preempt(bfqd))??????? //因搶占導致的bfqq失效??????? bfq_bfqq_expire(bfqd, bfqd->in_service_queue,false, BFQQE_PREEMPTED);}//bfqq派發的IO請求數全傳輸完成，并且bfqq處于st->idle tree已經很長時間則返回truestatic bool bfq_bfqq_idle_for_long_time(struct bfq_data *bfqd,??????????????????? struct bfq_queue *bfqq){??? /*bfqq->budget_timeout在bfqq最后一個IO請求完成被賦值jiffies，此時bfqq已經過期失效處于st->idle tree。然后過了大于等于bfqd->bfq_wr_min_idle_time時間(即bfqq->budget_timeout+ bfqd->bfq_wr_min_idle_time < jiffies)，bfqq綁定的進程要傳輸新的IO請求。這就是說bfqq已經idle很長時間了。*/??? return bfqq->dispatched == 0 &&??????? time_is_before_jiffies(//bfqq->budget_timeout+ bfqd->bfq_wr_min_idle_time < jiffies返回true??????????? bfqq->budget_timeout +??????????? bfqd->bfq_wr_min_idle_time);}
首先再說明一下，執行bfq_bfqq_handle_idle_busy_switch()函數的流程一般是__bfq_insert_request()->bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()，有兩種情況：
1：進程第一次傳輸IO請求，分配新的bfqq，而新分配bfqq默認就有bfq_bfqq_in_large_burst標記。
2：bfqq因配額消耗光等原因而過期失效，從st->active tree移動到st->idle tree，之后bfqq就處于idle狀態。然后等來了新的IO請求，執行該函數流程把bfqq激活，從st->idle tree移動到st->active tree。
當然，執行到bfq_bfqq_handle_idle_busy_switch()，就要判斷bfqq綁定進程的IO傳輸特性，判斷它是burst型IO？實時性IO？還是交互式IO？這些代碼整理如下：
1：burst型IO的判定：代碼是in_burst = bfq_bfqq_in_large_burst(bfqq)，bfqq有bfq_bfqq_in_large_burst標記則表示bfqq綁定的進程有一段時間內大量派發IO請求的特性，就是burst型IO，這個判斷比較簡單。
2：實時性IO的判定：代碼是soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&!BFQQ_TOTALLY_SEEKY(bfqq) &&!in_burst &&time_is_before_jiffies(bfqq->soft_rt_next_start) &&bfqq->dispatched == 0。這個判斷就復雜多了：bfqd->bfq_wr_max_softrt_rate默認大于0；!BFQQ_TOTALLY_SEEKY(bfqq)返回true，說明bfqq傳輸的IO是順序IO(磁盤是sata)或者bfqq每次傳輸的數據量很少(磁盤是ssd)，這個分析不一定合理，本文最后會詳細介紹；!in_burst是說bfqq沒有bfq_bfqq_in_large_burst標記，即不是burst型IO；time_is_before_jiffies(bfqq->soft_rt_next_start)是說，bfqq過期失效，從st->active tree移動到st->idle tree，bfqq處于idle狀態。在過了bfqq->soft_rt_next_start設定的時間后，bfqq又來了新的IO請求，則time_is_before_jiffies(bfqq->soft_rt_next_start)返回true。這個是判斷實時型IO的關鍵，在后續的文章在詳細介紹；bfqq->dispatched == 0是說bfqq之前的IO請求全傳輸完成了。
3：交互式IO的判定：代碼是*interactive = !in_burst && idle_for_long_time。就是說，bfqq不是in_burst型IO。idle_for_long_time為true的判定比較復雜，它是bfq_bfqq_idle_for_long_time()的返回值，源碼前文有貼。簡單說，在bfqq處于idle狀態(處于st->idle tree)后，在bfqq最后一個IO請求傳輸完成后，過了bfqd->bfq_wr_min_idle_time毫秒后，bfqq來了新的IO請求。感覺交互式IO的判斷主要是說，bfqq沒有大量IO傳輸的特性，但是會突然來了IO請求，必須低延時。
ok，除了這幾點，bfq_bfqq_handle_idle_busy_switch()函數中還有其他幾個關鍵要點。
arrived_in_time 變量： bfqq->ttime.last_end_request是bfqq最后一個IO請求傳輸完成的時間，arrived_in_time是true，說明bfqq最后一個IO請求傳輸完成后(此時bfqq已經過期失效)，在bfqd->bfq_slice_idle * 3這段空閑時間內，bfqq綁定的進程再次派發IO請求而執行該函數激活bfqq。為了bfqq綁定的進程IO延遲低，就要用bfqq搶占bfqd->in_service_queue，從而盡可能快的派發該bfqq綁定的進程新的IO請求。arrived_in_time此時是true，下邊執行bfq_bfqq_update_budg_for_activation()用到它，如果bfqq再有bfq_bfqq_non_blocking_wait_rq標記，則該函數返回true，說明bfqq很大可能會搶占bfqd->in_service_queue而盡可能快被調度使用作為新的bfqd->in_service_queue，這樣就可以盡可能塊派發bfqq新的IO請求。
bfq_bfqq_in_large_burst標記：代碼是in_burst = bfq_bfqq_in_large_burst(bfqq)。bfq_bfqq_in_large_burst 我的理解是，表示一段bfqq一段時間內大量派發IO請求，如果它派發IO后空閑了很長一段時間，那就說明bfqq不再具有bfqq_in_large_burst標記了，就清理掉。
bfq_bfqq_IO_bound標記 : 代碼是if (!bfq_bfqq_IO_bound(bfqq))里邊。表示向bfqq隊列插入IO請求很快。如果bfqq在傳輸完最后一個IO請求后(被移動到st->idle tree)的bfqd->bfq_slice_idle * 3時間內，又來新的IO請求則arrived_in_time為true。這樣bfqq->requests_within_timer就加1，如果這樣持續120次，bfqq->requests_within_timer大于120，那就再對bfqq設置bfq_bfqq_IO_bound標記。
最后，重點是bfq_bfqq_handle_idle_busy_switch()函數里執行bfq_update_bfqq_wr_on_rq_arrival()函數。這是根據根據進程的IO特性(burst型IO、實時性IO、還是交互式IO)，決定調整權重系數bfqq->wr_coeff。這個函數下邊講解。
2.2 調整權重系數bfqq->wr_coeff和真正提升進程bfqq的權重entity->weight
先看下bfq_update_bfqq_wr_on_rq_arrival()函數源碼
static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd,???????????????????????? struct bfq_queue *bfqq,???????????????????????? unsigned int old_wr_coeff,//bfqq老的的wr_coeff值，該函數里會更新它???????????????????????? bool wr_or_deserves_wr,//wr_or_deserves_wr為true表示bfqq的bfqq->wr_coeff大于1，或者bfqq是交互式或者實時同步IO???????????????????????? bool interactive,//interactive為true表示進程是交互式IO???????????????????????? bool in_burst,//in_burst為true表示進程是普通的大量傳輸IO???????????????????????? bool soft_rt)//soft_rt為true表示進程是實時性IO{??? //old_wr_coeff == 1 : bfqq老的wr_coeff是1，沒有權重提升??? //bfqq正在提升權重，或者bfqq是同步IO并且想要提升權重(因為bfqq是交互式IO或者實時性IO)，則wr_or_deserves_wr是1??? if (old_wr_coeff == 1 && wr_or_deserves_wr) {??????? /* start a weight-raising period */??????? //走這個分支說明bfqq是交互式IO??????? if (interactive) {//測試這里成立??????????? bfqq->service_from_wr = 0;??????????? //權重提升系數bfqq->wr_coeff更新為30,之后__bfq_entity_update_weight_prio()中根據bfqq->wr_coeff增加bfqq的權重??????????? bfqq->wr_coeff = bfqd->bfq_wr_coeff;??????????? //更新bfqq的權重提升時間bfqq->wr_cur_max_time為bfq_wr_duration()??????????? bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);??????? } else {??????? //走這個分支說明bfqq是實時IO??????????? //bfqq->wr_start_at_switch_to_srt賦值負無窮大??????????? bfqq->wr_start_at_switch_to_srt = bfq_smallest_from_now();??????????? //bfqq->wr_coeff更新 30*BFQ_SOFTRT_WEIGHT_FACTOR，顯然實時IO的bfqq權重提升系數更大??????????? bfqq->wr_coeff = bfqd->bfq_wr_coeff *??????????????? BFQ_SOFTRT_WEIGHT_FACTOR;??????????? //更新bfqq->wr_cur_max_time為實時性IO最大的權重提升時間bfqd->bfq_wr_rt_max_time??????????? bfqq->wr_cur_max_time =??????????????? bfqd->bfq_wr_rt_max_time;??????? }??????? bfqq->entity.budget = min_t(unsigned long,??????????????????????? bfqq->entity.budget,??????????????????????? 2 * bfq_min_budget(bfqd));}//走這個分支說明bfqq老的權重提升系數bfqq->wr_coeff大于1??? else if (old_wr_coeff > 1)??? {??????? //走這個分支說明bfqq是交互式IO，再次更新bfqq->wr_coeff和bfqq->wr_cur_max_time??????? if (interactive) {??????????? bfqq->wr_coeff = bfqd->bfq_wr_coeff;??????????? bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);??????? } else if (in_burst)?????????? //走這個分支說明bfqq是普通的大量傳輸IO,則還原權重提升系數bfqq->wr_coeff為1??????????? bfqq->wr_coeff = 1;??????? else if (soft_rt) {//走這個分支說明bfqq是實時性IO??????????? //如果bfqq->wr_cur_max_time不是實時性IO的最大的權重提升時間bfqd->bfq_wr_rt_max_time??????????? if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time) ??????????? {??????????????? //bfqq->wr_start_at_switch_to_srt更新為bfqq上次權重提升時間??????????????? bfqq->wr_start_at_switch_to_srt = bfqq->last_wr_start_finish;??????????????? //bfqq->wr_cur_max_time更新為實時性IO最大的權重提升時間??????????????? bfqq->wr_cur_max_time = bfqd->bfq_wr_rt_max_time;??????????????? //bfqq->wr_coeff更新 30*BFQ_SOFTRT_WEIGHT_FACTOR??????????????? bfqq->wr_coeff = bfqd->bfq_wr_coeff * BFQ_SOFTRT_WEIGHT_FACTOR;??????????? }??????????? ??????????? /*顯然，如果進程bfqq是實時性IO并且bfqq->wr_coeff在執行bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->???????????? bfq_update_bfqq_wr_on_rq_arrival()函數時bfqq->wr_coeff已經大于1，則更新bfqq->last_wr_start_finish=jiffies。就是說，實時性IO的進程bfqq權重提升后，每次執行到bfq_update_bfqq_wr_on_rq_arrival()都更新bfqq->last_wr_start_finish*/??????????? bfqq->last_wr_start_finish = jiffies;??????? }??? }}
注釋已經寫的比較清楚，這里再做個整體總結：
1:該函數的執行流程是: __bfq_insert_request ()->bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()，該函數的執行時機是bfqq是新創建的 或者 bfqq原本是idle狀態(bfqq的entity處于處于st->idle tree)。現在bfqq來了新的IO請求而要激活bfqq，首先在bfq_bfqq_handle_idle_busy_switch()根據bfqq的idle時間、bfqq的bfq_bfqq_in_large_burst標記等等，判定判斷bfqq的IO特性，是burst型IO(in_burst是1)? 實時性IO(soft_rt是1)? 交互式IO(interactive是1)?然后執行bfq_update_bfqq_wr_on_rq_arrival()根據bfqq的IO特性，更新bfqq->wr_coeff、bfqq->wr_cur_max_time、bfqq->last_wr_start_finish。
2：bfqq->wr_coeff是bfqq的權重提升系數，回到 bfq_bfqq_handle_idle_busy_switch()函數，執行 bfq_add_bfqq_busy->bfq_activate_bfqq->bfq_activate_requeue_entity->
__bfq_activate_requeue_entity->__bfq_activate_entity->bfq_update_fin_time_enqueue->__bfq_entity_update_weight_prio()，在__bfq_entity_update_weight_prio()中令bfqq的默認權重乘以bfqq->wr_coeff，就是增大bfqq的權重。
3：bfqq->wr_cur_max_time是進程的權重提升時間。派發IO請求時bfq_dispatch_rq_from_bfqq->bfq_update_wr_data，如果進程權重提升時間到了，則可能要執行bfq_bfqq_end_wr()就要令bfqq結束提升權重。
需要特別說明幾點
1:bfq_update_bfqq_wr_on_rq_arrival()的執行時機一般都是bfqq原本處于idle狀態(處于st->active tree)，bfqq有了新的IO請求，激活bfqq(把bfqq移入到st->active tree)。bfqq激活后，再向進程的bfqq添加IO請求，此時并不會執行到bfq_update_bfqq_wr_on_rq_arrival()，除非bfqq再次過期失效，處于idle狀態，被移入st->ilde tree。
2：bfqq->wr_start_at_switch_to_srt的更新時機，是bfq_update_bfqq_wr_on_rq_arrival()里因bfqq先被判定交互式IO。if (interactive)成立則bfqq->wr_cur_max_time = bfq_wr_duration(bfqd)和bfqq->wr_coeff=30。如果bfqq被判定是實時性IO，下邊的if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time)成立，則更新bfqq->wr_start_at_switch_to_srt = bfqq->last_wr_start_finish。
最后補充一點，if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time) 這個if什么情況下成立呢?我的分析是，bfqq原本處于idle狀態(處于st->ilde tree)，然后bfqq的進程來了新的IO請求，執行到bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()函數，判斷bfqq是交互式IO，if (interactive)成立，則執行bfqq->wr_coeff=30和bfqq->wr_cur_max_time = bfq_wr_duration(bfqd)。然后bfqq派發完IO請求，過期失效，再次處于idle狀態。
接著bfqq綁定的進程又來的新的IO請求，還是執行bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()，但是bfqq綁定的進程被判定是實時性IO，下邊的if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time)成立，則再次增大bfqq->wr_coeff和bfqq->wr_cur_max_time。
前文提過，__bfq_insert_request ()->bfq_add_request()->bfq_bfqq_handle_idle_busy_switch()->bfq_update_bfqq_wr_on_rq_arrival()只會增大bfqq的權重系數bfqq->wr_coeff，真正提升權重是在緊接著執行的bfq_bfqq_handle_idle_busy_switch()->bfq_add_bfqq_busy->bfq_activate_bfqq->bfq_activate_requeue_entity->__bfq_activate_requeue_entity->__bfq_activate_entity->bfq_update_fin_time_enqueue->__bfq_entity_update_weight_prio()函數，源碼不復雜，如下：
//主要是根據bfqq->wr_coeff計算bfqq新的權重struct bfq_service_tree * __bfq_entity_update_weight_prio(struct bfq_service_tree *old_st,//entity所屬調度器st??????????????? struct bfq_entity *entity,??????????????? bool update_class_too){??? ...................??? //老的調度器st->wsum減去entity->weight??? old_st->wsum -= entity->weight;??? if (entity->new_weight != entity->orig_weight) ??? {??????? if (entity->new_weight < BFQ_MIN_WEIGHT ||entity->new_weight > BFQ_MAX_WEIGHT) {??????????? //更新entity->new_weight??????????? if (entity->new_weight < BFQ_MIN_WEIGHT)??????????????? entity->new_weight = BFQ_MIN_WEIGHT;??????????? else??????????????? entity->new_weight = BFQ_MAX_WEIGHT;??????? }??????? //更新entity->orig_weight??????? entity->orig_weight = entity->new_weight;??????? //更新bfqq->ioprio??????? if (bfqq)??????????? bfqq->ioprio = bfq_weight_to_ioprio(entity->orig_weight);??????? .................??????? new_st = bfq_entity_service_tree(entity);??????? prev_weight = entity->weight;??????? //根據bfqq->wr_coeff計算bfqq新的權重，很明顯bfqq->wr_coeff越大計算出的權重越大??????? new_weight = entity->orig_weight * (bfqq ? bfqq->wr_coeff : 1);??????? ...............??????? ///把新的權重更新到bfqq的entity->weight??????? entity->weight = new_weight;??????? ..........??????? //調度器的st->wsum累加entity新的權重entity->weight??????? new_st->wsum += entity->weight;??? }??? //測試new_st 和 old_st是同一個??? return new_st;}
2.3 結束提升進程bfqq的權重
進程bfqq的權重不是一直提升的，總有結束的時刻，什么時間會結束呢？在派發IO請求的過程bfq_dispatch_rq_from_bfqq->bfq_update_wr_data()，有概率結束進程bfqq的權重，下邊看下bfq_update_wr_data()源碼：
//如果bfqq的權重提升時間用完了 或者 bfqq因權重提升消耗的配額達到了限制，則結束bfqq權重提升，bfqq->wr_coeff恢復為1等static void bfq_update_wr_data(struct bfq_data *bfqd, struct bfq_queue *bfqq){??? struct bfq_entity *entity = &bfqq->entity;??? if (bfqq->wr_coeff > 1) { /* queue is being weight-raised */??????? //bfqq擁有bfq_bfqq_in_large_burst標記的話，就不能再權重提升了，要結束權重提升??????? if (bfq_bfqq_in_large_burst(bfqq))??????????? //bfqq結束權重提升，bfqq->wr_coeff 和 bfqq->last_wr_start_finish恢復到權重提升前的狀態等等??????????? bfq_bfqq_end_wr(bfqq);??????? /*bfqq->last_wr_start_finish是bfqq權重更新開始時間，bfqq->wr_cur_max_time是bfqq權重更新時間，該if成立說明bfqq的權重更新時間用完了，則可能就需要令bfqq->wr_coeff 和 bfqq->last_wr_start_finish恢復到權重提升前的狀態等等*/? ??????else if (time_is_before_jiffies(bfqq->last_wr_start_finish +??????????????????????? bfqq->wr_cur_max_time)) ??????? {??????????? /*這個if是說，如果是交互式IO的bfqq的提升權重時間過了bfqq->wr_cur_max_time毫秒，或者bfqq由交互式IO特性切換到實時性IO特性而進一步提升了權重，又過了bfq_wr_duration(bfqd)毫秒，則執行bfq_bfqq_end_wr()令bfqq結束權重提升*/??????????? if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time ||??????????????? time_is_before_jiffies(bfqq->wr_start_at_switch_to_srt + bfq_wr_duration(bfqd)))??????????????? //bfqq結束權重提升，bfqq->wr_coeff 和 bfqq->last_wr_start_finish恢復到權重提升前的狀態等等??????????????? bfq_bfqq_end_wr(bfqq);??????????? else {??????????????? //bfqq回到權重提升狀態，增大bfqq->wr_coeff到30，更新bfqq->wr_cur_max_time為權重提升時間??????????????? switch_back_to_interactive_wr(bfqq, bfqd);??????????????? //bfqq->entity.prio_changed置1表示bfqq->wr_coeff更新了??????????????? bfqq->entity.prio_changed = 1;??????????? }??????? }??????? /*bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time表示bfqq是交互式IO而提升權重，見bfq_update_bfqq_wr_on_rq_arrival()。bfqq->service_from_wr > max_service_from_wr 表示因bfqq權重提升而消耗的配額超過上限。這個if判斷是說，如果交互式IO的進程在權重提升后消耗的配額超過max_service_from_wr則要結束bfqq的權重提升了。這樣的話，實時性IO進程權重提升是沒有配額限制的，交互式IO進程權重提升是有配額限制的*/??????? if (bfqq->wr_coeff > 1 &&??????????? bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time &&??????????? bfqq->service_from_wr > max_service_from_wr) {??????????? //bfqq結束權重提升，bfqq->wr_coeff 和 bfqq->last_wr_start_finish恢復到權重提升前的狀態等等? ? ? ? ? ? ? ? ?bfq_bfqq_end_wr(bfqq);? ? ? ? ??}??? }??? if ((entity->weight > entity->orig_weight) != (bfqq->wr_coeff > 1))??????? //這里是重點，主要是根據最新的bfqq->wr_coeff計算bfqq新的權重??????? __bfq_entity_update_weight_prio(bfq_entity_service_tree(entity),??????????????????????? entity, false);}
注釋寫的比較清楚，有幾個重點再說下：
if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time || time_is_before_jiffies(bfqq->wr_start_at_switch_to_srt + bfq_wr_duration(bfqd)))的判斷，有兩種情況if成立：
1：bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time表示進程bfqq是交互式IO而提升權重。
2：time_is_before_jiffies(bfqq->wr_start_at_switch_to_srt + bfq_wr_duration(bfqd))說明進程bfqq由交互式特性IO切換到是實時性IO，更新bfqq->wr_start_at_switch_to_srt(見bfq_update_bfqq_wr_on_rq_arrival())，并把bfqq->wr_coeff 進一步更新到 30*BFQ_SOFTRT_WEIGHT_FACTOR，然后把bfqq激活。之后派發bfqq上的IO請求，執行到bfq_dispatch_rq_from_bfqq->bfq_update_wr_data()，此時過了bfq_wr_duration(bfqd)毫秒，則該if成成立。
if ((entity->weight > entity->orig_weight) != (bfqq->wr_coeff > 1))，if成立有兩種情況：
1：(entity->weight > entity->orig_weight) 并且bfqq->wr_coeff == 1?
2：(entity->weight<=entity->orig_weight)并且bfqq->wr_coeff > 1
第1種情況是說，bfqq原本權重提升，bfqq->wr_coeff >1，但是bfqq的權重提升時間用完了或者bfqq因權重提升消耗的配額達到了限制，則上邊執行bfq_bfqq_end_wr()結束bfqq權重提升而令bfqq->wr_coeff=1，此時if成立，執行__bfq_entity_update_weight_prio()真正減小bfqq的權重。第2種情況，是bfqq還沒有提升權重，但是bfqq->wr_coeff > 1，if成立，執行__bfq_entity_update_weight_prio()真正增大bfqq的權重。
3：bfq_update_io_thinktime
在向bfqq插入IO請求的過程，會執行bfq_update_io_thinktime()、bfq_update_has_short_ttime()、bfq_update_io_seektime()函數更新thinktime、short_ttime、seektime幾個重要的參數，源碼如下：
static bool __bfq_insert_request(struct bfq_data *bfqd, struct request *rq){??? //更新ttime->ttime_samples、ttime->ttime_total、ttime->ttime_mean??? bfq_update_io_thinktime(bfqd, bfqq);??? //更新bfqq的has_short_ttime狀態??? bfq_update_has_short_ttime(bfqd, bfqq, RQ_BIC(rq));??? //這里邊更新bfqq->seek_history??? bfq_update_io_seektime(bfqd, bfqq, rq);??? ..........? ??//把IO請求添加到bfqq->sort_list鏈表，并選擇合適的IO請求賦于bfqq->next_rq。接著可能激活bfqq，把bfqq添加到st->active tree??? bfq_add_request(rq);}
這里先看下bfq_update_io_thinktime()里對thinktime的更新：
//__bfq_insert_request()->bfq_update_io_thinktime()static void bfq_update_io_thinktime(struct bfq_data *bfqd,??????????????????? struct bfq_queue *bfqq){??? struct bfq_ttime *ttime = &bfqq->ttime;??? /*elapsed是bfqq上最近一次的IO請求傳輸完成到添加本次IO請求到bfqq的時間，這段時間bfqq是空閑狀態，這就是thinktime吧。elapsed應該可以理解成bfqq每傳輸的兩個IO請求之間的空閑時間，越大說明bfqq綁定的進程向bfqq插入IO請求越慢*/??? u64 elapsed = ktime_get_ns() - bfqq->ttime.last_end_request;??? //取最小時間??? elapsed = min_t(u64, elapsed, 2ULL * bfqd->bfq_slice_idle);??? //ttime->ttime_samples應該可以這樣理解，每次執行到該函數令ttime->ttime_samples增加8??? ttime->ttime_samples = (7*bfqq->ttime.ttime_samples + 256) / 8;??? //ttime->ttime_total應該可以理解成每次增加8*elapsed，elapsed越大，ttime->ttime_total越大??? ttime->ttime_total = div_u64(7*ttime->ttime_total + 256*elapsed,? 8);??? //ttime->ttime_mean顯然是ttime->ttime_total除以ttime->ttime_samples??? ttime->ttime_mean = div64_ul(ttime->ttime_total + 128,???????????????????? ttime->ttime_samples);}
什么是thinktime？thinktime有什么意義？需要先看下有關的ttime->ttime_samples、ttime->ttime_total、ttime->ttime_mean的3個參數。
bfq_update_io_thinktime()的執行時機是在向bfqq插入IO請求時。每插入一個IO請求，bfqq->ttime.ttime_samples增加8，ttime->ttime_total是累加時間差elapsed*8，ttime->ttime_mean是ttime->ttime_samples除以ttime->ttime_mean。因此，簡單理解下，bfqq->ttime.ttime_samples是每派發一個IO請求則加8，ttime->ttime_total是累加bfqq最近一次IO請求傳輸完成的時間與插入本次IO請求到bfqq的時間，ttime->ttime_mean是ttime->ttime_total/bfqq->ttime.ttime_samples。
再簡單理解，ttime->ttime_samples可以理解成是bfqq傳輸的IO請求數，ttime->ttime_total是bfqq每傳輸的兩個IO請求之間的空閑時間之和，ttime->ttime_mean是平均bfqq每傳輸的兩個IO請求之間的空閑時間。ttime->ttime_mean越大，說明bfqq綁定的進程向bfqq插入IO請求越慢。
4：bfq_bfqq_has_short_ttime和bfq_update_io_seektime
bfqq默認就有bfq_bfqq_has_short_ttime標記，是在bfqq創建時。它的更新是在bfq_update_has_short_ttime()函數，如下：
//__bfq_insert_request()->bfq_update_has_short_ttime()static void bfq_update_has_short_ttime(struct bfq_data *bfqd,?????????????????????? struct bfq_queue *bfqq,?????????????????????? struct bfq_io_cq *bic){??? //has_short_ttime默認是true??? bool has_short_ttime = true, state_changed;??? ....................??? //這個if可能會成立嗎?正常情況bfqq->split_time負無窮大，該if正常應該不會成立??? if (time_is_after_eq_jiffies(bfqq->split_time +???????????????????? bfqd->bfq_wr_min_idle_time))? ? ? ? ??return;??? /*ttime->ttime_mean越大，說明bfqq綁定的進程向bfqq插入IO請求越慢。該if此時bfqq->ttime.ttime_mean > bfqd->bfq_slice_idle成立。bfq_sample_valid(bfqq->ttime.ttime_samples)為true說明傳輸的IO請求數大于80。二者都成立，說明，進程向bfqq->sort_list插入IO請求太慢了，于是has_short_ttime = false，下邊則會bfq_clear_bfqq_has_short_ttime。*/if (atomic_read(&bic->icq.ioc->active_ref) == 0 || ???? //bfqq->ttime.ttime_samples大于80??????? (bfq_sample_valid(bfqq->ttime.ttime_samples) &&??????? //bfqq->ttime.ttime_mean大于8ms???????? bfqq->ttime.ttime_mean > bfqd->bfq_slice_idle))? ? ? ? ? ? ? ? has_short_ttime = false;??? ....................??? state_changed = has_short_ttime != bfq_bfqq_has_short_ttime(bfqq);??? if (has_short_ttime)? ? ? ? ?bfq_mark_bfqq_has_short_ttime(bfqq);??? else? ? ? ? ? bfq_clear_bfqq_has_short_ttime(bfqq);??? ....................}
bfq_bfqq_has_short_ttime應該是說bfqq擁有短時間快速向bfqq插入IO請求的一種屬性，bfqq默認有這種屬性，但是如果向bfqq插入IO請求太慢就會清理掉該屬性。bfq_bfqq_has_short_ttime標記的應用應該是在idling_boosts_thr_without_issues()函數比較明顯，說明進程向bfqq->sort_list插入IO請求很快，在bfqq派發IO請求沒有了，bfqq->sort_list是空，先不讓bfqq過期失效，而是啟動idle timer，等一小段時間，看bfqq有沒有來新的IO請求，沒有的話再令bfqq過期失效，這樣可以提升性能。
seektime與bfqq的BFQQ_SEEKY屬性有關，相關源碼如下：
//__bfq_insert_request()->bfq_update_io_seektime()static voidbfq_update_io_seektime(struct bfq_data *bfqd, struct bfq_queue *bfqq,?????????????? struct request *rq){??? /*bfqq->seek_history左移一位，每派發一個seek IO，bfqq->seek_history的bit0就置1，并且左移一位。bfqq派發的seek IO越多，bfqq->seek_history的是1的bit位越多*/??? bfqq->seek_history <<= 1;??? //根據bfqq前后派發的兩個IO的扇區地址和本次派發IO的字節數，判斷出本次派發的IO是seek IO的話，則把bfqq->seek_history的bit0置1??? bfqq->seek_history |= BFQ_RQ_SEEKY(bfqd, bfqq->last_request_pos, rq);??? if (bfqq->wr_coeff > 1 &&??????? bfqq->wr_cur_max_time == bfqd->bfq_wr_rt_max_time &&??????? BFQQ_TOTALLY_SEEKY(bfqq))? ? ? ? ? ? ? bfq_bfqq_end_wr(bfqq);}
判斷seek io以及相關的宏定義在下邊：
//判斷是否是seek io#define BFQ_RQ_SEEKY(bfqd, last_pos, rq) (get_sdist(last_pos, rq) > BFQQ_SEEK_THR &&?? \????????? ?(!blk_queue_nonrot(bfqd->queue) ||blk_rq_sectors(rq) < BFQQ_SECT_THR_NONROT))//計算bfqq->seek_history有多少個bit位是1#define BFQQ_SEEKY(bfqq)??? (hweight32(bfqq->seek_history) > 19)#define BFQQ_TOTALLY_SEEKY(bfqq)??? (bfqq->seek_history & -1)
重點是BFQ_RQ_SEEKY，它正是判斷seek io的。而BFQQ_SEEKY為true說明bfqq派發的IO中有大于19個seek io。只要bfqq有一個seek io則BFQQ_TOTALLY_SEEKY返回true，如果bfqq派發的IO沒有一個seek io，BFQQ_TOTALLY_SEEKY才會返回false。
因此，重點是判斷seek io的BFQ_RQ_SEEKY宏定義。它返回true有兩種情況：
1：磁盤是ssd時，前后兩次傳輸的IO請求前后扇區地址相差大于800個扇區并且本次傳輸的IO請求扇區數小于64
2：磁盤是sata時，前后兩次傳輸的IO請求前后扇區地址相差大于800個扇區
我對seek io做個簡單總結，不一定合理：磁盤是sata時派發的IO是隨機IO，則是seek io；磁盤是ssd時派發的IO傳輸的數據量(即扇區數)很少。
5：bfq_bfqq_IO_bound 和 bfq_bfqq_in_large_burst再談談
bfqq的bfq_bfqq_IO_bound 和 bfq_bfqq_in_large_burst標記，前文已經說下，這里再總結下。在把bfqq激活插入st->active tree時執行的bfq_bfqq_handle_idle_busy_switch()函數里，有概率執行bfq_clear_bfqq_in_large_burst和bfq_mark_bfqq_IO_bound。
static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,???????????????????????? struct bfq_queue *bfqq,???????????????????????? int old_wr_coeff,???????????????????????? struct request *rq,???????????????????????? bool *interactive){??? //bfqq在傳輸完最后一個IO請求后的bfqd->bfq_slice_idle * 3時間內又來新的IO請求則arrived_in_time為true??? arrived_in_time =? ktime_get_ns() <=??????????? bfqq->ttime.last_end_request +??????????? bfqd->bfq_slice_idle * 3;??? ..........................??? //bfqq有bfq_bfqq_in_large_burst標記則in_burst為true,in_burst表示bfqq綁定的進程有一段時間內大量派發IO請求的特性??? in_burst = bfq_bfqq_in_large_burst(bfqq);??? ..........................??? /*如果bfqq不是新創建的(就是說是處于st->ilde tree)，并且bfqq空閑很長時間idle_for_long_time，并且在bfqq最后一個IO請求傳輸完成的時間點bfqq->budget_timeout后，過了10s+ bfqq才來了新的IO請求而激活它，于是清理bfqq_in_large_burst標記。bfq_bfqq_in_large_burst 我的理解是，表示一段bfqq一段時間內大量派發IO請求，如果它派發IO后空閑了很長一段時間，那就說明bfqq不再具有bfqq_in_large_burst標記了，該清理掉*/??? if (likely(!bfq_bfqq_just_created(bfqq)) &&//bfqq不是新創建的(就是說是處于st->ilde tree)??????? idle_for_long_time &&//bfqq空閑很長時間??????? time_is_before_jiffies(//bfqq->budget_timeout + 10s < jiffies，就是說 bfqq->budget_timeout后已經過了10s+??????????? bfqq->budget_timeout +????????? ??msecs_to_jiffies(10000))) {? ? ? ? ? ? ? ??//從bfqq->burst_list_node鏈表剔除? ? ? ? ? ? ? ? hlist_del_init(&bfqq->burst_list_node);? ? ? ? ? ? ? ??//清理掉 bfq_bfqq_in_large_burst 標記? ? ? ? ? ? ? ??bfq_clear_bfqq_in_large_burst(bfqq);??? }??? .........................??? //如果bfqq被清理了bfq_bfqq_IO_bound標記??? if (!bfq_bfqq_IO_bound(bfqq)) {??????? /*bfqq在傳輸完最后一個IO請求后(被移動到st->idle tree)的bfqd->bfq_slice_idle * 3時間內又來新的IO請求則arrived_in_time為true，這樣bfqq->requests_within_timer就加1。如果這樣持續120次，bfqq->requests_within_timer大于120，那就再對bfqq設置bfq_bfqq_IO_bound標記。但是又一次不成立，就對bfqq->requests_within_timer*/??????? if (arrived_in_time) {? ? ? ? ? ? ? bfqq->requests_within_timer++;? ? ? ? ? ? ??//bfqd->bfq_requests_within_timer默認120? ? ? ? ? ? ??if (bfqq->requests_within_timer >=bfqd->bfq_requests_within_timer)? ? ? ? ? ? ? ? ? ?bfq_mark_bfqq_IO_bound(bfqq);??????? } else? ? ? ? ? ? ?bfqq->requests_within_timer = 0;??? }}
bfq_bfqq_in_large_burst表示bfqq大量快速傳輸IO請求，不會空閑較長時間。burst 型IO就是靠它判定的。如果bfqq過期失效被移入st->idle tree，過了很長時間bfqq才來新的IO請求，就要清理掉bfqq的 bfq_bfqq_in_large_burst標記。顯然，bfqq空閑時間太長了，不再具備大量快速傳輸IO請求特性了。
bfqq默認就有bfq_bfqq_IO_bound標記，如果bfqq因為BFQQE_TOO_IDLE過期失效而執行bfq_bfqq_expire()函數，并且bfqq只消耗了很少的配額，則執行bfq_clear_bfqq_IO_bound清理掉bfq_bfqq_IO_bound標記。如下：
void bfq_bfqq_expire(struct bfq_data *bfqd,???????????? struct bfq_queue *bfqq,???????????? bool compensate,???????????? enum bfqq_expiration reason){//如果bfqq超時原因是BFQQE_TOO_IDLE，并且bfqq只消化了很小一部分配額則令clear bfq_clear_bfqq_IO_bound。??? /*bfqq創建時默認就有bfq_bfqq_IO_bound屬性，如果bfqq的IO請求派發完了但是配額沒消耗光，則bfq_completed_request()中可能啟動idle_slice_timer 定時器，并設置bfq_mark_bfqq_wait_request。等idle_slice_timer定時時間到，執行bfq_idle_slice_timer_body()，bfqq依然沒來新的IO請求，于是就令bfqq因BFQQE_TOO_IDLE而過期失效。執行到這里，bfqq消耗的配額只有不到entity->budget的五分之一，于是清理bfqq的bfq_bfqq_IO_bound屬性。因此，可以看出來，bfq_bfqq_IO_bound應該表示bfqq表示短時間大量傳輸IO請求的屬性，如果bfqq沒有短時間大量傳輸IO請求就過期失效，就清理掉該屬性。*/??? if (reason == BFQQE_TOO_IDLE &&??????? entity->service <= 2 * entity->budget / 10)? ? ? ? ? ? ??bfq_clear_bfqq_IO_bound(bfqq);}
什么情況下bfqq會因為BFQQE_TOO_IDLE過期失效呢？注釋里說的比較清楚。如果bfqq的IO請求派發完了但是配額沒消耗光，在bfqq最后一個IO請求傳輸完成，執行bfq_completed_request()函數。在該函數里沒有立即令bfqq過期失效，因為bfqq可能馬上就來了新的IO請求。于是啟動idle_slice_timer 定時器，并設置bfq_mark_bfqq_wait_request標記。等idle_slice_timer定時時間到，執行定時器函數bfq_idle_slice_timer_body()，bfqq依然沒來新的IO請求，于是就令bfqq因BFQQE_TOO_IDLE而過期失效。
執行bfq_mark_bfqq_IO_bound對bfqq加上bfq_bfqq_IO_bound標記是在bfq_bfqq_handle_idle_busy_switch()函數。注釋說的比較清楚，簡單說bfqq處于ilde狀態(st->idle? tree)并且最后一個IO請求傳輸完成，在bfqd->bfq_slice_idle * 3時間內bfqq來了新的IO請求。這樣持續多次，就bfq_mark_bfqq_IO_bound對bfqq加上bfq_bfqq_IO_bound標記。idling_boosts_thr_without_issues()會根據bfq_bfqq_IO_bound標記，判斷bfqq是否可能會來新的IO請求，會來的話則該函數返回true。
因此，覺得bfq_bfqq_IO_bound標記是說，在bfqq空閑時，很快就會來新的IO請求并插入到bfqq的隊列。那bfq_bfqq_has_short_ttime和bfq_bfqq_IO_bound有什么區別呢？我覺得bfq_bfqq_has_short_ttime反應的是在bfqq已經激活狀態下(bfqq的entity處于st->active tree，準確說正在派發bfqq上的IO請求)，進程快速向bfqq的隊列插入IO請求的特性。
本文是我閱讀bfq源碼的一些理解，可能有理解不對的地方。水平有限，本文如有錯誤請指出。
總結
以上是生活随笔為你收集整理的内核block层IO调度器—bfq算法深入探索2的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
