- 论坛徽章:
- 0
|
本帖最后由 remaper 于 2013-04-15 23:37 编辑
最近看了几天文件系统相关的代码(刚如行,很菜,问得不好莫怪)。想梳理一下bio被处理的流程
我所看的内核版本是:2.6.34.14
1、plug和unplug的含义没理解(不是什么激活不激活,而是这两个东西的具体角色,所参与的工作,结合流程来分析),plug和unplug的时机分别是什么?
2、从执行submit_bio之后,再到__make_request再到q->request_fn(),整个过程似乎是串行的。当然,__make_request未必会执行q->request_fn(),只有会在下面的情况下,才会触发:
out:
if (unplug || !queue_should_plug(q))
__generic_unplug_device(q);
所以又回到了第一个问题。submit_bio就感觉是在攒bio,攒的差不多了就触发了上面的代码,继而会执行q->request_fn()函数。,而q->request_fn是驱动提供的,实际上只是处理了一个request,似乎没别的。
3、在drivers/block/hd.c里,hd的request_queue竟然是一个全局的静态变量,那就是说所有硬盘的bio都会通过同一个队列来处理。
为什么不是一个物理设备,一个request_queque,因为我觉得这样可能并行会更好一点,至少解耦。
4、在block/blk-merge.c的blk_rq_map_sg函数里,new_segment的时候总是:
...
sg->page_link &= ~0x02;
sg = sg_next(sg);
}
sg_set_page(sg, bvec->bv_page, nbytes, bvec->bv_offset);
而sg_next(sg)是有可能返回NULL的,但是sg_set_page并没有对sg检查,那内核怎么保证,sg_next返回非NULL?
|
|