真实的I/O调度层处理

1.5.6 真实的I/O调度层处理

现在我们块设备也有了，队列也有了，要提交请求也就可以开始提交了。那就让我们回到generic_make_request来研究一下如何提交请求如何处理请求吧。我们看到，函数最后调用q->make_request_fn(q, bio)。对 make_request_fn 函数的调用可以认为是 IO调度层的入口，该函数用于向请求队列中添加请求。该函数是在创建请求队列时指定的，代码如下（blk_init_queue 函数中）：

q->request_fn = rfn;

blk_queue_make_request(q, __make_request);

 

前面看到函数 blk_queue_make_request 将函数 __make_request 的地址赋予了请求队列 q 的 make_request_fn 成员：

 

void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn)

{

       q->nr_requests = BLKDEV_MAX_RQ;

       q->make_request_fn = mfn;

……

 

那么，__make_request函数才是IO调度层的真实入口，来自block/ll_rw_blk.c：

 

2846static int __make_request(request_queue_t *q, struct bio *bio)

2847{

2848        struct request *req;

2849        int el_ret, rw, nr_sectors, cur_nr_sectors, barrier, err, sync;

2850        unsigned short prio;

2851        sector_t sector;

2852

2853        sector = bio->bi_sector;

2854        nr_sectors = bio_sectors(bio);

2855        cur_nr_sectors = bio_cur_sectors(bio);

2856        prio = bio_prio(bio);

2857

2858        rw = bio_data_dir(bio);

2859        sync = bio_sync(bio);

2860

2861        /*

2862         * low level driver can indicate that it wants pages above a

2863         * certain limit bounced to low memory (ie for highmem, or even

2864         * ISA dma in theory)

2865         */

2866        blk_queue_bounce(q, &bio);

2867

2868        spin_lock_prefetch(q->queue_lock);

2869

2870        barrier = bio_barrier(bio);

2871        if (unlikely(barrier) && (q->next_ordered == QUEUE_ORDERED_NONE)) {

2872                err = -EOPNOTSUPP;

2873                goto end_io;

2874        }

2875

2876        spin_lock_irq(q->queue_lock);

2877

2878        if (unlikely(barrier) || elv_queue_empty(q))

2879                goto get_rq;

2880

2881        el_ret = elv_merge(q, &req, bio);

2882        switch (el_ret) {

2883                case ELEVATOR_BACK_MERGE:

2884                        BUG_ON(!rq_mergeable(req));

2885

2886                        if (!q->back_merge_fn(q, req, bio))

2887                                break;

2888

2889                        blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);

2890

2891                        req->biotail->bi_next = bio;

2892                        req->biotail = bio;

2893                        req->nr_sectors = req->hard_nr_sectors += nr_sectors;

2894                        req->ioprio = ioprio_best(req->ioprio, prio);

2895                        drive_stat_acct(req, nr_sectors, 0);

2896                        if (!attempt_back_merge(q, req))

2897                                elv_merged_request(q, req);

2898                        goto out;

2899

2900                case ELEVATOR_FRONT_MERGE:

2901                        BUG_ON(!rq_mergeable(req));

2902

2903                        if (!q->front_merge_fn(q, req, bio))

2904                                break;

2905

2906                        blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);

2907

2908                        bio->bi_next = req->bio;

2909                        req->bio = bio;

2910

2911                        /*

2912                         * may not be valid. if the low level driver said

2913                         * it didn't need a bounce buffer then it better

2914                         * not touch req->buffer either...

2915                         */

2916                        req->buffer = bio_data(bio);

2917                        req->current_nr_sectors = cur_nr_sectors;

2918                        req->hard_cur_sectors = cur_nr_sectors;

2919                        req->sector = req->hard_sector = sector;

2920                        req->nr_sectors = req->hard_nr_sectors += nr_sectors;

2921                        req->ioprio = ioprio_best(req->ioprio, prio);

2922                        drive_stat_acct(req, nr_sectors, 0);

2923                        if (!attempt_front_merge(q, req))

2924                                elv_merged_request(q, req);

2925                        goto out;

2926

2927                /* ELV_NO_MERGE: elevator says don't/can't merge. */

2928                default:

2929                        ;

2930        }

2931

2932get_rq:

2933        /*

2934         * Grab a free request. This is might sleep but can not fail.

2935         * Returns with the queue unlocked.

2936         */

2937        req = get_request_wait(q, rw, bio);

2938

2939        /*

2940         * After dropping the lock and possibly sleeping here, our request

2941         * may now be mergeable after it had proven unmergeable (above).

2942         * We don't worry about that case for efficiency. It won't happen

2943         * often, and the elevators are able to handle it.

2944         */

2945        init_request_from_bio(req, bio);

2946

2947        spin_lock_irq(q->queue_lock);

2948        if (elv_queue_empty(q))

2949                blk_plug_device(q);

2950        add_request(q, req);

2951out:

2952        if (sync)

2953                __generic_unplug_device(q);

2954

2955        spin_unlock_irq(q->queue_lock);

2956        return 0;

2957

2958end_io:

2959        bio_endio(bio, nr_sectors << 9, err);

2960        return 0;

2961}

 

__make_request 函数比较复杂，它接收request_queue类型的描述符q和一个bio结构的描述符bio作为其参数，然后执行如下操作：

 

2853内部变量sector赋值为bio的bi_sector字段，即将传送的bio的第一个扇区。2854行通过bio_sectors(bio)宏得到需要传送多少个连续的扇区，并赋值给内部变量nr_sectors。bio_sectors宏来自include/linux/bio.h

#define bio_sectors(bio) ((bio)->bi_size >> 9)

 

bio->bi_size我们知道，在前面如果一个页中的4个块内容连续，则do_mpage_readpage通过调用bio_add_page将4个块的大小4096赋值给bio的bi_size字段，那么nr_sectors就是4096>>9，等于8，表示这个bio一共8个扇区待传输。

 

2866行，如果需要，调用blk_cqueue_bounce()函数建立一个回弹缓冲区。如果回弹缓冲区被建立，__make_request()函数将对该缓冲区而不是原先的bio结构进行操作。关于回弹缓冲区的相关知识，请查阅相关资料，这里我们不做过多的介绍。

 

2878行，调用I/O调度程序的elv_queue_empty()函数检查请求队列中是否存在待处理请求——注意，调度队列可能是空的，但是I/O调度程序的其他队列可能包含待处理请求。如果没有待处理请求，那么调用blk_plug_device()函数插入请求队列，然后跳转到2932行的get_rq标号处。

 

如果插入的请求队列包含待处理请求，则走到2881行调用I/O调度程序的elv_merge()函数检查新的bio结构是否可以并入已存在的请求中。

 

该函数将返回三个可能值：

1. ELEVATOR_NO_MERGE：已经存在的请求中不能包含bio结构；这种情况下，跳转到2932行的get_rq标号处。

2. ELEVATOR_BACK_MERGE：bio结构可作为末尾的bio而插入到某个请求req中；这种情形下，函数调用q->back_merge_fn方法检查是否可以扩展该请求。如果不行，则跳转到2932行的get_rq标号处。否则，将bio描述符插入req链表的末尾并更新req的相应字段值。然后，函数试图将该请求与其后面的请求合并（新的bio可能填充在两个请求之间）。

3. ELEVATOR_FRONT_MERGE：bio结构可作为某个请求req的第一个bio被插入；这种情形下，函数调用q->front_merge_fn方法检查是否可以扩展该请求。如果不行，则跳转到2932行的get_rq标号处。否则，将bio描述符插入req链表的首部并更新req的相应字段值。然后，试图将该请求与其前面的请求合并。

 

不管是ELEVATOR_BACK_MERGE还是ELEVATOR_FRONT_MERGE，说明bio已经被并入存在的请求中，跳转到2951行out标号处终止函数。

 

下面来看2932行的get_rq标号处，bio必须被插人到一个新的请求中。那么通过get_request_wait给我们这个分区的请求队列q分配一个新的请求描述符request。如果没有空闲的内存，get_request_wait函数将调用io_schedule挂起当前进程，直到设置了bio->bi_rw中的BIO_RW_AHEAD标志，该标志表明这个I/O操作是一次预读；在这种情形下，调用bio_endio()并终止：此时将不会执行数据传送。

 

然后调用2945行的init_request_from_bio(req, bio)初始化请求描述符中的字段。主要有：

a) 根据bio描述符的内容初始化各个字段，包括扇区数、当前bio以及当前段。

b) 设置flags字段中的REQ_CMD标志（说明这次request是一个标准的读或写操作）。

c) 如果第一个bio段的页框存放在低端内存，则将buffer字段设置为缓冲区的线性地址。

d) 将rc_disk字段设置为bio->bi_bdev->bd_disk的地址。

e) 将bio插入请求链表。

f) 将start_time字段设置为jiffies的值。

 

回到__make_request的2948-2949行，再次调用elv_queue_empty检查一下请求队列中是否存在待处理请求。如果没有待处理请求，那么调用blk_plug_device()函数插入请求队列。不管怎样，都会执行2950行的add_request函数：

 

static inline void add_request(request_queue_t * q, struct request * req)

{

       drive_stat_acct(req, req->nr_sectors, 1);

 

       if (q->activity_fn)

              q->activity_fn(q->activity_data, rq_data_dir(req));

 

       /*

        * elevator indicated where it wants this request to be

        * inserted at elevator_merge time

        */

       __elv_add_request(q, req, ELEVATOR_INSERT_SORT, 0);

}

 

add_request函数本质上调用__elv_add_request函数通过电梯算法把这个新的request插入到对应requesr_queue合适的位置。在介绍__elv_add_request函数之前，我们先介绍几个宏，来自include/linux/elevator.h：

 

    155 /*

    156  * Insertion selection

    157  */

    158 #define ELEVATOR_INSERT_FRONT   1

    159 #define ELEVATOR_INSERT_BACK    2

    160 #define ELEVATOR_INSERT_SORT    3

    161 #define ELEVATOR_INSERT_REQUEUE 4

 

很明显，在add_request函数中传递进来的是ELEVATOR_INSERT_SORT，表示从前面插入。那么带着这个where我们进入下一个函数，即__elv_add_request。来自block/elevator.c：

 

    646 void __elv_add_request(request_queue_t *q, struct request *rq, int where,

    647                        int plug)

    648 {

    649         if (q->ordcolor)

    650                 rq->cmd_flags |= REQ_ORDERED_COLOR;

    651

    652         if (rq->cmd_flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)) {

    653                 /*

    654                  * toggle ordered color

    655                  */

    656                 if (blk_barrier_rq(rq))

    657                         q->ordcolor ^= 1;

    658

    659                 /*

    660                  * barriers implicitly indicate back insertion

    661                  */

    662                 if (where == ELEVATOR_INSERT_SORT)

    663                         where = ELEVATOR_INSERT_BACK;

    664

    665                 /*

    666                  * this request is scheduling boundary, update

    667                  * end_sector

    668                  */

    669                 if (blk_fs_request(rq)) {

    670                         q->end_sector = rq_end_sector(rq);

    671                         q->boundary_rq = rq;

    672                 }

    673   } else if (!(rq->cmd_flags & REQ_ELVPRIV) && where == ELEVATOR_INSERT_SORT)

    674                 where = ELEVATOR_INSERT_BACK;

    675

    676         if (plug)

    677                 blk_plug_device(q);

    678

    679         elv_insert(q, rq, where);

    680 }

 

传入的参数plug等于0，所以blk_plug_device()不会被执行。很明显，一路走来我们根本没有设置什么REQ_SOFTBARRIER、REQ_HARDBARRIER或REQ_ELVPRIV标识，所以前面都和我们无关，直接跳到最后一行这个elv_insert()：

 

    548 void elv_insert(request_queue_t *q, struct request *rq, int where)

    549 {

    550         struct list_head *pos;

    551         unsigned ordseq;

    552         int unplug_it = 1;

    553

    554         blk_add_trace_rq(q, rq, BLK_TA_INSERT);

    555

    556         rq->q = q;

    557

    558         switch (where) {

    559         case ELEVATOR_INSERT_FRONT:

    560                 rq->cmd_flags |= REQ_SOFTBARRIER;

    561

    562                 list_add(&rq->queuelist, &q->queue_head);

    563                 break;

    564

    565         case ELEVATOR_INSERT_BACK:

    566                 rq->cmd_flags |= REQ_SOFTBARRIER;

    567                 elv_drain_elevator(q);

    568                 list_add_tail(&rq->queuelist, &q->queue_head);

    569                 /*

    570                  * We kick the queue here for the following reasons.

    571                  * - The elevator might have returned NULL previously

    572                  *   to delay requests and returned them now.  As the

    573                  *   queue wasn't empty before this request, ll_rw_blk

    574                  *   won't run the queue on return, resulting in hang.

    575                  * - Usually, back inserted requests won't be merged

    576                  *   with anything.  There's no point in delaying queue

    577                  *   processing.

    578                  */

    579                 blk_remove_plug(q);

    580                 q->request_fn(q);

    581                 break;

    582

    583         case ELEVATOR_INSERT_SORT:

    584                 BUG_ON(!blk_fs_request(rq));

    585                 rq->cmd_flags |= REQ_SORTED;

    586                 q->nr_sorted++;

    587                 if (rq_mergeable(rq)) {

    588                         elv_rqhash_add(q, rq);

    589                         if (!q->last_merge)

    590                                 q->last_merge = rq;

    591                 }

    592

    593                 /*

    594                  * Some ioscheds (cfq) run q->request_fn directly, so

    595                  * rq cannot be accessed after calling

    596                  * elevator_add_req_fn.

    597                  */

    598                 q->elevator->ops->elevator_add_req_fn(q, rq);

    599                 break;

    600

    601         case ELEVATOR_INSERT_REQUEUE:

    602                 /*

    603                  * If ordered flush isn't in progress, we do front

    604                  * insertion; otherwise, requests should be requeued

    605                  * in ordseq order.

    606                  */

    607                 rq->cmd_flags |= REQ_SOFTBARRIER;

    608

    609                 /*

    610                  * Most requeues happen because of a busy condition,

    611                  * don't force unplug of the queue for that case.

    612                  */

    613                 unplug_it = 0;

    614

    615                 if (q->ordseq == 0) {

    616                         list_add(&rq->queuelist, &q->queue_head);

    617                         break;

    618                 }

    619

    620                 ordseq = blk_ordered_req_seq(rq);

    621

    622                 list_for_each(pos, &q->queue_head) {

    623                         struct request *pos_rq = list_entry_rq(pos);

    624                         if (ordseq <= blk_ordered_req_seq(pos_rq))

    625                                 break;

    626                 }

    627

    628                 list_add_tail(&rq->queuelist, pos);

    629                 break;

    630

    631         default:

    632                 printk(KERN_ERR "%s: bad insertion point %d/n",

    633                        __FUNCTION__, where);

    634                 BUG();

    635         }

    636

    637         if (unplug_it && blk_queue_plugged(q)) {

    638                 int nrq = q->rq.count[READ] + q->rq.count[WRITE]

    639                         - q->in_flight;

    640

    641                 if (nrq >= q->unplug_thresh)

    642                         __generic_unplug_device(q);

    643         }

    644 }

 

由于我们是从前面插，所以我们执行562行这个list_add，struct request有一个成员struct list_head queuelist，而struct request_queue有一个成员struct list_head queue_head，所以我们就把前者插入到后者所代表的这个队伍中来。然后咱们就返回了。

 

以上所有操作全部完成后，在终止之前，2952行检查是否设置了bio->bi_rw中的BIO_RW_SYNC标志。如果是，则对“请求队列”调用generic_unplug_device()函数以卸载设备驱动程序，并直接调用q->request_fn(q)，这个函数是什么，马上会看到。

 

如果在调用__make_request()函数之前请求队列不是空的，那么说明该请求队列要么已经被拔掉过，要么很快将被拔掉——因为每个拥有待处理请求的插入请求队列q都有一个正在运行的动态定时器q->unplug_timer。另一方面，如果请求队列是空的，则__make_request()函数插入请求队列。或迟（最坏的情况是当拔出的定时器到期了）或最早（从__make_request()中退出时，如果设置了bio的BIO_RW_SYNC标志），该请求队列都会被拔掉。任何情形下，块设备驱动程序的策略例程最后都将处理调度队列中的请求。

 

当generic_make_request执行完scsi磁盘设备对应请求队列的q->make_request_fn方法，也就是刚才分析的__make_request以后，块设备的调度层就结束了。至于包含该bio的request放入到请求队列中后，何时被处理就由 IO 调度器的调度算法决定了。一旦该请求能够被处理，便调用请求队列中request_fn 字段所指向的函数处理。这个成员的初始化也是在创建请求队列时设置的：

 

   1590 struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)

   1591 {

   1592         struct request_queue *q;

   1593

   1594         q = __scsi_alloc_queue(sdev->host, scsi_request_fn);

   1595         if (!q)

   1596                 return NULL;

   1597

   1598         blk_queue_prep_rq(q, scsi_prep_fn);

   1599         blk_queue_issue_flush_fn(q, scsi_issue_flush_fn);

   1600         blk_queue_softirq_done(q, scsi_softirq_done);

   1601         return q;

   1602 }

 

我们看到，给scsi设备创建request_queue的时候，是把scsi_request_fn作为他的request_fn 字段所指向的函数地址，所以这个scsi_request_fn就是scsi底层驱动的入口。