摘要
linux block layer第一篇介绍了bio数据结构及bio内存管理，本文章介绍bio的提交、拆分、io请求合并、io请求完成时的回调处理。由于“bio的提交”涉及内容太多，所以该小节只描述一些概要信息，在介绍完multi-queue机制后（待整理），再对着代码细说submit_bio流程。
内核源码：linux-5.10.3
一、bio的提交（submit）
提交bio的函数是submit_bio，这个函数做完account工作统计读写量后，调用submit_bio_noacct进行实际的提交操作。submit_bio_noacct根据存储设备是否定义了自己的提交函数（见struct block_device_operations中的submit_bio成员，比如dm设备执行dm_submit_bio），执行不同的操作。
图1 处理bio的路径
blk_mq_submit_bio将bio提交给存储设备处理，bio经不同路径被提交至不同的链表，最终由器件的host controller处理。bio的处理路径见图1，后继文章（待整理）会对代码细节展开描述。图1遵循以下原则：
1）按照路径标号值从小到大顺序，决策路径流。
2）io调度器队列、软件队列ctx是二选一关系。若存储设备有调度器，则启用io调度器队列，否则启用软件队列ctx。
路径1：flush、fua类型且有数据需要传输的bio执行此路径流。这类bio需要尽快分发给器件处理，不能缓存在上层队列中，否则会因io调度等不可控因素导致该bio延迟处理。这类bio首先被加入requeu list，rq加入requeu list后立即唤醒高优先级的工作队列线程kbockd，将rq其从requeue list移至硬件队列hctx头，并执行blk_mq_run_hw_queue将rq分发给器件处理。引入requeue list是为了复用已有代码，尽量让block flush代码着眼于flush机制本身，外围工作交给已有代码，可以使代码独立、精简。
路径2：io发起者执行了blk_start_plug（发起者预计接下来有多个io请求时，会执行此函数），且满足条件：“硬件队列数量为1”或者“存储设备定义了自己的commit_rqs函数”或者“存储设备是旋转的机械磁盘”，并且存储设备使用了io调度器，执行此路径流。这个场景是针对慢速存储设备的，将rq暂存至进程自己的plug list，然后将plug list中rq移至io调度器队列，由调度器选择合适的rq下发给器件处理。
路径3：io发起者执行了blk_start_plug（发起者预计接下来有多个io请求时，会执行此函数），且硬件队列hctx不忙的情况下，执行此路径流。这种场景充分利用存储器件处理能力，将rq在进程级plug list中短暂暂存后，将plug list中的rq尽快地下发给处于不忙状态的器件处理。
路径4：io发起者执行了blk_start_plug（发起者预计接下来有多个io请求时，会执行此函数），且存储器件没有使用io调度器、且硬件队列hctx处于busy状态，执行此路径流。这是一个通用场景，rq先在进程级的plug list缓存，然后存在软件队列ctx中，接着存至硬件队列hctx，最后分发给器件处理。
路径5：存储设备存在io调度器，执行此路径流。rq被放入调度器队列，由调度器决定rq的处理顺序。既然存在io调度器，就把rq交给调度器处理吧。
路径6：io发起者执行了blk_start_plug（发起者预计接下来有多个io请求时，会执行此函数），且存储设备设置了QUEUE_FLAG_NOMERGES（不允许合并io请求）、且没有io调度器，执行此路径流。这个场景下，仅做有限的合并，若bio与plug list中的rq可以合并则合并，否则就添加到plug中。plug list存在属于相同存储设备的rq，尝试将bio合并到plug list的rq，接着执行blk_mq_try_issue_directly将plug list中的rq发送到下层队列中，这体现了“有限合并”的含义，且只做一次合并，另外也意味着，任何时候，在plug list中只属于一个存储设备的rq有且只有一个。
路径7：未使用io调度器的前提下，硬件队列数量大于1且io请求是同步请求，或者硬件队列hctx不忙，执行此路径流。io请求通过rq->q->mq_ops->queue_rq（nvme设备回调函数是nvme_queue_rq）分发至host controller。
路径8：默认处理路径，上面路径条件都不满足，执行此路径流。这个路径是没有io调度器的（如果有调度器，执行路径5）。举些例子，在没有io调度器、没有启动plug list的前提下，执行该路径流：
1）如果是emmc、ufs这些单队列设备，io请求就执行此路径流。
2）如果是nvme这类支持多硬件队列的设备，io请求是异步的，执行此路径流。
3）如果是nvme这类支持多硬件队列的设备，io请求是同步的，但硬件队列busy，执行此路径流。
二、bio的拆分（split）
提交bio过程中，视情况，需要对bio拆分、合并（拆分后得到的bio不允许合并），逻辑图见图2。
图2 bio的拆分、合并
单个bio处理的数据大小是有限制的，这些限制参数存放在struct queue_limits结构体中。当bio处理的数据大小超出限制，这个bio就会被拆分成多个满足条件的bio，并组成一个chain，然后依次处理这些bio，直至chain中的所有bio处理完。
| 类型 | discard、 secure erase | write zeroes | write same | read、write |
| 块设备层 | max_discard_sectors | 无 | 无 | max_sectors |
| 器件 | max_hw_discard_sectors discard_granularity discard_alignment | max_write_zeroes_sectors | max_write_same_sectors | chunk_sectors logical_block_size physical_block_size max_segments max_segment_size virt_boundary_mask |
表1 io请求限制参数
1，参数说明
1）discard类bio
max_discard_sectors：block layer下发的单个discard大小的上限。
max_hw_discard_sectors：device能处理的单个discard大小的上限。
max_discard_sectors要小于等于max_hw_discard_sectors。
device处理大范围的discard比较耗时，将导致其他io较大的延迟。通过在block layer对单个discard的大小进行限制，将大范围的discard拆分成多个满足限制条件的小范围discard，从而减少其他io的延迟。
discard_granularity：discard操作的最小单元，值为0表示不支持discard。
discard_alignment：理解这个参数需要知道logic sector、physical sector概念（参考flash存储器件介绍，待整理）。physical sector是存储器件一次读写的最小单元，大小是logical sector的整数倍。内核filesystem、block layer都是基于512B sector设计的（即physical sector = 512B），现如今出现了sector大于512B 的器件（例如physical sector = 4K），为了适配内核，flash器件firmware逻辑上将physical sector分成多个512B大小的segment，这里的segment就称为logical sector。文件系统可以访问任意的logical sector，firmware读取logical sector所属的physical sector后，经过处理，返回对应logical sector的数据。分区可以从任意一个logical sector开始（即可以不与physical sector边界对齐，但这会降低性能）。图3用一个physical sector包含4个logical sector的例子（另假设dicard granularity等于1个physical sector大小）来说明这些概念的关系。
在上图中，dicard_alignment=7*512 bytes。
2）write zero类bio
write zero又称作single overwrite、zero fill erase、zero-fill。清零操作用于擦除device上的数据，防止数据被恢复、泄露，执行write zero后，读到的数据都是0。
max_write_zeroes_sectors：单次清零操作可以处理的最大范围。值为0代表device不支持write zero。
3）write same类bio
max_write_same_sectors：单个write same命令可以处理的最大范围。
4）read、write类bio
max_sectors：block layer允许单个io处理的数据长度上限，小于等于max_hw_sectors。
chunk_sectors：NVMe 1.3支持NOIOB（Namespace Optimal IO Boundaries），read、write请求涉及的sector不横跨（cross）chunk_sectors时（即按chunk_sectors对齐时），性能最佳（横跨chunk_sectors时，需要读2个chunk，没有横跨时只需读1个chunk）。值为0表示不支持chunk_sectors。如果NVMe低版本协议没有定义NOIOB，那么chunk_sectors等于max_hw_sectors，否则设置为NVMe器件定义的值struct nvme_id_ns->noiob（见nvme_set_chunk_sectors函数）。
图4 chunk_sectors示意图
logical_blo ck_size：device能够寻址的最小单元（参考图3说明）。
physical_block_size：device执行读写操作的最小单元（（参考图3说明））。
max_segments：一个io请求包含的segment数量的最大值（struct bio结构体成员bi_io_vec是一个链表，链表的成员称作vector，vector描述的内存区域称作segment，详细描述见https://blog.csdn.net/geshifei/article/details/119959905）。
max_segment_size：一个segment的最大长度。
virt_boundary_mask：segment结束地址按其对齐。除第一个segment的起始地址、最后一个segment的结束地址可以不用对齐，其他的segment的起止地址需要按virt_boundary_mask对齐。
2，代码分析
write zeroes、write same的拆分很简单，仅需考虑一个限制参数，将bio按照该限制值进行拆分即可。discard类、read-write类不但要考虑大小限制，还得考虑boundary对齐，尽量使拆分后形成的每个bio能够按粒度对齐，这样才能达到最大的性能或者达到最优的状态。
1）discard类bio的拆分
先看一个例子，假设discard_alignment=0、discard_granularity=64、max_discard_sectors=128、bio对[2，257]范围内的sector执行discard的场景，如果仅仅根据max_discard_sectors分割bio，那么该bio将被拆分成[2，129]、[130，257]2个bio（每一个bio处理128个sector），如下图：
图5 未考虑discard粒度进行拆分（有问题，[128，191]没有discard）
对于bio1而言，器件不会对[128，129]执行discard。因为器件认为[130，191]这些sector中的数据是有效的，所以不能执行discard，如果对[128，129]执行discard，由于discard最小粒度限制，势必会将[130，191]这些sector也discard掉。同理[130，191]这些sector也没有执行discard。最终的效果是连续的、按粒度对齐的、满足max_discard_sectors要求的[128，191]共64个sector没有执行discard，这显然不是我们期望的。
正确的做法是：拆分一个bio时，将discard_alignment、discard_granularity限制条件考虑进去，拆分后形成的第1个bio起始sector可以不满足限制条件，但能确保后继bio的起始sector满足条件，这样就可以让拆分后形成的bio最多只可能有2个bio不能执行discard（第1个bio的起始sector不满足限制条件、最后一个bio的结束sector不满足限制条件）。对[2，257]范围内的sector执行discard，将会拆分成[2，127]、[128，255]、[256，257]这3个bio，[63，255]这些sector被执行discard（不会出现连续的、对齐的、满足粒度要求的[128，191]共64个sector没有执行discard的情况）。
图6 考虑discard粒度进行拆分（正确方法）
discard类bio拆分流程见：
submit_bio --> submit_bio_noacct --> __submit_bio_noacct_mq --> blk_mq_submit_bio --> __blk_queue_split --> blk_bio_discard_split：
| //split bio要计算从bio中拆分出多少个的sector，作为拆分后得到的第一个bio的数据长度。即计算出第一个bio的结束位置，让后继的bio的起始sector都能满足表1限制条件， 62 static struct bio *blk_bio_discard_split(struct request_queue *q, 63 struct bio *bio, 64 struct bio_set *bs, 65 unsigned *nsegs) 66 { 67 unsigned int max_discard_sectors, granularity; 68 int alignment; 69 sector_t tmp; 70 unsigned split_sectors; 71 72 *nsegs = 1; 73 //将单个bio能处理的最大sector数量按discard粒度对齐，(max_discard_sectors % granularity）得到的余数部分对执行discard来说是没有意义的，因不满足最小粒度要求，器件是不会这些sector执行discard的，以避免属于同粒度范围内的其他sector也被discard掉。 74 /* Zero-sector (unknown) and one-sector granularities are the same. */ 75 granularity = max(q->limits.discard_granularity >> 9, 1U); 76 77 max_discard_sectors = min(q->limits.max_discard_sectors, 78 bio_allowed_max_sectors(q)); 79 max_discard_sectors -= max_discard_sectors % granularity; 80 81 if (unlikely(!max_discard_sectors)) { 82 /* XXX: warn */ 83 return NULL; 84 } 85 //判断bio待处理的sector数量，如果小于一次能处理的最大值，那么是不需要拆分的，直接返回。 86 if (bio_sectors(bio) <= max_discard_sectors) 87 return NULL; 88 //从89行开始，进入拆分逻辑，找到第一个bio的结束位置。 //一个bio能处理的最多sector数量不能超过max_discard_sectors，所以这里设置拆分出来的新bio的sector数量为max_discard_sectors。 89 split_sectors = max_discard_sectors; 90 91 /* 92 * If the next starting sector would be misaligned, stop the discard at 93 * the previous aligned sector. 94 */ //计算偏移量内（discard_alignment）的sector有多少个sector不满足一个粒度要求。 95 alignment = (q->limits.discard_alignment >> 9) % granularity; 96 //bio->bi_iter.bi_sector + split_sectors - alignment计算拆分后得到的第一个bio的结束sector号，确保从第2个的bio开始，他们的起始sector号（也即前一个bio的结束sector号）都是按physical logical对齐的。参考图3，如果一个分区的起始sector不是按physical sector对齐的，那么bio->bi_iter.bi_sector + split_sectors算出来的第一个bio的结束sector大概率（除了某个些特定的bio->bi_iter.bi_sector值）是无法按physical sector对齐（因为split_sectors已经是按granularity对齐，也必定按physical sector对齐，所以未按physical sector对齐的bio->bi_iter.bi_sector加上已经按physical sector对齐的split_sectors，最终得到的值肯定也不能按physical sector对齐）。解决方法是做个减法，让partition的起始sector按照physical sector对齐，即减去：（sectors of discard alignment）% （sectors of discard granularity）。 97 tmp = bio->bi_iter.bi_sector + split_sectors - alignment; //下面几行代码，将前面计算出的第一个bio结束sector号，但该sector可能没按discard granularity，这几行代码做个调整，将第一个bio的结束的sector按granularity对齐。最终，达到使第一个bio的结束sector号按physical sector对齐、按discard granularity对齐。 98 tmp = sector_div(tmp, granularity); 99 100 if (split_sectors > tmp) 101 split_sectors -= tmp; 102 //前面已经计算出需要从bio中拆分出多少个sector，下面开始实际的拆分操作 103 return bio_split(bio, split_sectors, GFP_NOIO, bs); 104 } |
2）read、write类bio拆分
需考虑3个条件：
第1个条件，一些器件不允许segment list存在gap，如果bio中的segment存在gap，则需要拆分（Another restriction inherited for NVMe - those devices don't support SG lists that have "gaps" in them. Gaps refers to cases where the previous SG entry doesn't end on a page boundary. For NVMe, all SG entries must start at offset 0 (except the first) and end on a page boundary (except the last).）。由virt_boundary_mask决定。
第2个条件，不能超过单个io请求能处理的最多sectors数量。由get_max_io_size函数根据max_sectors、chunk_sectors、logical_block_size、physical_block_size这几个参数计算得出。
第3个条件，不能超过单个io请求能处理的做多segment数量。由queue_max_segments函数根据max_segments、max_segment_size这几个参数计算得出。
read、write类bio拆分流程见：
submit_bio --> submit_bio_noacct --> __submit_bio_noacct_mq --> blk_mq_submit_bio --> __blk_queue_split --> blk_bio_segment_split
| 251 static struct bio *blk_bio_segment_split(struct request_queue *q, 252 struct bio *bio, 253 struct bio_set *bs, 254 unsigned *segs) 255 { 256 struct bio_vec bv, bvprv, *bvprvp = NULL; 257 struct bvec_iter iter; 258 unsigned nsegs = 0, sectors = 0; //根据限制参数，计算出一个io请求允许的max sectors、max segments。 259 const unsigned max_sectors = get_max_io_size(q, bio); 260 const unsigned max_segs = queue_max_segments(q); 261 262 bio_for_each_bvec(bv, bio, iter) { 263 /* 264 * If the queue doesn't support SG gaps and adding this 265 * offset would create a gap, disallow it. 266 */ //检查第1个条件（见前面描述），segment list是否有gap，如果有，就需要拆分。 267 if (bvprvp && bvec_gap_to_prev(q, bvprvp, bv.bv_offset)) 268 goto split; 269 //累加每个bio vector（也即bio segment）的sector，检查第2个条件看看是否超出max sectors，如果超出，就需要拆分。 bvec_split_segs函数中，还会检查第3个条件，看看累加的segment值是否超过max segments，如果超过了，也需要拆分。 270 if (nsegs < max_segs && 271 sectors + (bv.bv_len >> 9) <= max_sectors && 272 bv.bv_offset + bv.bv_len <= PAGE_SIZE) { 273 nsegs++; 274 sectors += bv.bv_len >> 9; 275 } else if (bvec_split_segs(q, &bv, &nsegs, §ors, max_segs, 276 max_sectors)) { 277 goto split; 278 } 279 280 bvprv = bv; 281 bvprvp = &bvprv; 282 } 283 284 *segs = nsegs; 285 return NULL; 286 split: 287 *segs = nsegs; //bio_split函数进行实际的拆分。新申请一个bio结构体（称作split bio），并复制原bio中的信息，将split bio读写数据的长度split->bi_iter.bi_size，并更新原bio的bvec_iter信息（用于bvec_iter只是bio完成的情况，因为拆分出去一部分交由split bio处理了，所以拆分出去的部分对于原bio而言视为已处理完成）。 288 return bio_split(bio, sectors, GFP_NOIO, bs); 289 } |
代码中涉及segment的概念，图示如下。
图7 vector与segment
拆分后的bio通过submit_bio --> submit_bio_noacct --> __submit_bio_noacct_mq --> blk_mq_submit_bio --> __blk_queue_split --> bio_chain形成chain（用struct bio的bi_private成员组成链表），并给新分配的bio设置REQ_NOMERGE标记，不允许该bio做merge操作。bio拆分示意图见图8。
图8 bio拆分示意图
三、请求的合并（merge）
1，合并的类型
io请求的合指bio的合并、rq的合并。submit_bio的入参是struct bio结构体，bio如果不能被合并到已有的rq中，就需要新申请一个rq存放bio，如果能合并到已有的rq中，rq中多个bio通过struct bio->bi_next 组成链表，链入struct request->biotail。
read、write类型请求合并存在ELEVATOR_BACK_MERGE、ELEVATOR_FRONT_MERGE两种类型。
ELEVATOR_BACK_MERGE：如果待合并的bio的结束sector号=rq中bio结束sector号，则将bio合并到已有bio的后面。
ELEVATOR_FRONT_MERGE：如果待合并的bio的结束sector号=rq中bio起始sector号，则将bio合并到已有bio的前面。
discard类型请求不关系请求的起止sector号，只要合并后不超过单个discard请求允许的max segment、max sector就可以合并。
图9展示了read、write类bio合并的过程，新提交的bio1、bio2、bio3需要尝试合并到已有的request A，request B中：
bio1的结束sector号等于rq A的起始sector号，做ELEVATOR_FRONT_MERGE。
bio2的起始sector号等于rq A的结束sector号，做ELEVATOR_BACK_MERGE。
bio2合并到rq A后，rq A、rqB变成连续空间，又可以做合并。
bio3不能合并到任何rq中，需要新申请一个struct request结构体存放bio3信息。
图9 read、write类型bio合并示意图
2，合并的目的
一个io的处理需要经由block layer、IO controller、device、hard IRQ、soft IRQ的处理，路径是很长的，在这些路径中会产生额外的开销。多个io请求合并成一个io，额外开销就很小。
multi-queue中硬件队列的tags数量是固定的（每一个tags与一个struct request关联），io请求超出tags限制值，需等待空闲可用的tags。
3，合并的策略
在不违反表1限制条件的情况下，才可以合并。可通过/sys/block/XX/queue/nomerges设置合并策略，见图10。
图10 io请求合并策略
4，代码分析
blk_mq_submit_bio代码：
| blk_qc_t blk_mq_submit_bio(struct bio *bio) { __blk_queue_split(&bio, &nr_segs); // bio拆分 if (!bio_integrity_prep(bio)) goto queue_exit; //plug list merge：尝试将入参bio合并到plug list管理的rq中。 blk_queue_nomerges判断q有没有QUEUE_FLAG_NOMERGES标记，如果有就不尝试merge。 if (!is_flush_fua && !blk_queue_nomerges(q) && blk_attempt_plug_merge(q, bio, nr_segs, &same_queue_rq)) goto queue_exit; //调度器 merge：尝试将入参bio合并到调度器队列或者软件队列ctx管理的rq中。 if (blk_mq_sched_bio_merge(q, bio, nr_segs)) goto queue_exit; rq_qos_throttle(q, bio); |
| bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio, unsigned int nr_segs, struct request **same_queue_rq) { struct blk_plug *plug; struct request *rq; struct list_head *plug_list; //当前进程没有启用plug list机制，直接退出 plug = blk_mq_plug(q, bio); if (!plug) return false; plug_list = &plug->mq_list; //遍历plug list中的rq（注意这里不需要加锁。若是将bio合并到调度器队列或者软件队列管理的rq中，就需要加锁。在无锁状态做merge操作，这是引入plug list的一个原因。） list_for_each_entry_reverse(rq, plug_list, queuelist) { if (rq->q == q && same_queue_rq) { /* * Only blk-mq multiple hardware queues case checks the * rq in the same queue, there should be only one such * rq in a queue **/ //same_queue_rq作用见前文描述的路径6，用于实现“有限合并”，确保任何时候，在plug list中属于一个存储设备的rq有且只有一个。 *same_queue_rq = rq; } if (rq->q != q) continue; //在plug list中找到了属于同一个存储器件的io请求rq，尝试将bio合并到这个rq中。 if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == BIO_MERGE_OK) return true; } return false; } |
| static enum bio_merge_status blk_attempt_bio_merge(struct request_queue *q, struct request *rq, struct bio *bio, unsigned int nr_segs, bool sched_allow_merge) { //检查软件层面的一些限制，合并的bio必须都是读或者都是写，io优先级必须一样，必须属于同一个存储器件等等。 if (!blk_rq_merge_ok(rq, bio)) return BIO_MERGE_NONE; //通过blk_try_merge选择合并策略，见前文 switch (blk_try_merge(rq, bio)) { //back merge，见前文。通过struct bio->bi_next 组成链表，链入struct request->biotail。 case ELEVATOR_BACK_MERGE: if (!sched_allow_merge || blk_mq_sched_allow_merge(q, rq, bio)) return bio_attempt_back_merge(rq, bio, nr_segs); break; //front merge，见前文。 case ELEVATOR_FRONT_MERGE: if (!sched_allow_merge || blk_mq_sched_allow_merge(q, rq, bio)) return bio_attempt_front_merge(rq, bio, nr_segs); break; //discard merge，见前文。 case ELEVATOR_DISCARD_MERGE: return bio_attempt_discard_merge(q, rq, bio); default: return BIO_MERGE_NONE; } return BIO_MERGE_FAILED; } |
以back merge为例（front merge、discard merge代码大同小异）：
| static enum bio_merge_status bio_attempt_back_merge(struct request *req, struct bio *bio, unsigned int nr_segs) { const int ff = bio->bi_opf & REQ_FAILFAST_MASK; //检查merge会不会导致单个io请求的max sector、max segment超出限制，检查merge会不会引起segment的“gap”。 if (!ll_back_merge_fn(req, bio, nr_segs)) return BIO_MERGE_FAILED; trace_block_bio_backmerge(req->q, req, bio); rq_qos_merge(req->q, req, bio); if ((req->cmd_flags & REQ_FAILFAST_MASK) != ff) blk_rq_set_mixed_merge(req); //将bio合并到已有rq管理的bio中 req->biotail->bi_next = bio; req->biotail = bio; req->__data_len += bio->bi_iter.bi_size; bio_crypt_free_ctx(bio); blk_account_io_merge_bio(req); return BIO_MERGE_OK; } |
四、io完成时的处理（completion）
以multi queue + nvme为例，io完成时流程如下：
图11 io完成时的处理流程
1，nvme注册硬中断处理函数nvme_irq
nvme初始化时执行reset work，注册irq函数。调用链为nvme_reset_work --> nvme_setup_io_queues --> nvme_setup_irqs --> queue_request_irq。
| static int queue_request_irq(struct nvme_queue *nvmeq) { struct pci_dev *pdev = to_pci_dev(nvmeq->dev->dev); int nr = nvmeq->dev->ctrl.instance; //注册中断处理函数 if (use_threaded_interrupts) { return pci_request_irq(pdev, nvmeq->cq_vector, nvme_irq_check, nvme_irq, nvmeq, "nvme%dq%d", nr, nvmeq->qid); } else { return pci_request_irq(pdev, nvmeq->cq_vector, nvme_irq, NULL, nvmeq, "nvme%dq%d", nr, nvmeq->qid); } } |
2，block注册软中断处理函数blk_done_softirq
subsys_initcall(blk_mq_init)，这个subsys_initcall函数在《linux block layer第一篇bio 子系统数据结构及初始化》中已经描述过，系统启动过程中会执行blk_mq_init函数。这里只看blk_mq_init函数实现：
| static int __init blk_mq_init(void) { int i; for_each_possible_cpu(i) INIT_LIST_HEAD(&per_cpu(blk_cpu_done, i)); //注册block软中断 open_softirq(BLOCK_SOFTIRQ, blk_done_softirq); cpuhp_setup_state_nocalls(CPUHP_BLOCK_SOFTIRQ_DEAD, "block/softirq:dead", NULL, blk_softirq_cpu_dead); cpuhp_setup_state_multi(CPUHP_BLK_MQ_DEAD, "block/mq:dead", NULL, blk_mq_hctx_notify_dead); cpuhp_setup_state_multi(CPUHP_AP_BLK_MQ_ONLINE, "block/mq:online", blk_mq_hctx_notify_online, blk_mq_hctx_notify_offline); return 0; } subsys_initcall(blk_mq_init); |
3，blk_done_softirq代码分析
blk_done_softirq执行rq的complete回调函数rq->q->mq_ops->complete(rq)，即nvme_pci_complete_rq。调用链如下，注意何时会执行bio、rq的回调函数：
nvme_pci_complete_rq
|--- nvme_complete_rq
|--- nvme_end_rq
|--- blk_mq_end_request
|--- blk_update_request
| |--- req_bio_endio
| |--- bio_endio
|--- __blk_mq_end_request
|--- rq->end_io（如果有回调的话），否则blk_mq_free_request