真实的I/O调度层处理

最新推荐文章于 2022-08-09 14:43:07 发布

苍月代表我

最新推荐文章于 2022-08-09 14:43:07 发布

阅读量772

点赞数

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;