文件读写，从请求到IO启动


在Linux中，块设备的读写是一个比较复杂的过程。如果再加上VFS的话，层次就更多了。实际上VFS和块设备驱动联系的不是非常密切。在VFS中，我们会看到当发生读写请求的时候，会调用ll_rw_block函数或者submit_bh函数，其中ll_rw_block是对submit_bh的封装。这个函数，实际上就是从VFS到实际设备读写的必经之路。关于这一点，有很多用systemtap来观测io的脚本就是在submit_bh函数安装一个stub（有关io检测的相关的文章，可以参看淘宝的大牛诸霸的博客）。



在这里，我们不再谈论VFS的东西，而是从submit_bh开始看起，然后到数据被读出，进程又继续执行的流程。
submit_bh的功能正如其函数的名字那样–“提交buffer head”。那么，具体提交给谁呢？由谁来提交呢？其实块设备的读写似乎是一个C/S架构的服务器。客户端是各个进行io操作的进程，服务器端就是设备的请求队列。进程把请求的信息包装成一个request的数据结构，然后，挂载在服务端，即块设备的请求队列中。我前面说的那句话“似乎是一个C/S架构的”，而不是真正C/S架构的。因为，C/S架构来源于网络程序，客户端进程把数据发往正在监听的服务端，然后服务端的进程从网络缓冲区中经过网络协议的层层解压“剥皮”，拿到数据。而我们谈论这个文件数据的读写并不真正是C/S架构的，原因就是，客户端的发送和服务端的接收请求全由一个进程，即用户进程来完成的。这一点应该很好理解，因为在OS中，除了中断以及异常处理没有上下文外，其他的都有进程上下文，因此，从submit读写请求到接收读写请求，当然就是进程自己的事情了，当然，如果你要是抬杠“在内核中完全可以由一个专门的线程用来处理服务端的事情”，我也无话可说。原理上，你这个抬杠当然是行得通的。说到这里，我想起了微内核的MINIX，就此打住，继续回到他们的处理过程中。
当用户进程提交请求，并挂载到块设备队列的过程中，还涉及一个IO调度的问题，即是，用户进程在提交一个请求时，遇到了调度算法，这个调度算法做的事情很简单，它检查这个请求和正在排队的请求能否合二为一。如果不能合二为一，那就直接挂上去。至此，一个进程所要做的工作基本上就结束了。可是，请求被相应的时机呢？什么时候，它的请求才能满足？
我们清楚，一个硬件设备，特别是块设备，让它来读取数据然后内核再从端口里面把数据提出来，或者说，通过DMA的方式，直接从磁盘中拿到数据，这个数据读出来的过程是很漫长的，这个漫长是相对于CPU来说的，绝对时间其实是很短暂的。一般情况下，用户进程在往块设备的请求队列上挂请求的时候，发现队列为空的话，会将该队列插入到一个全局的队列中(tq_disk，从名字中，我们也能够看出来是task queue for disk的缩写)。如果队列不为空，那么说明该队列已经加入到tq_disk的全局队列中了，既然该块设备的读写请求队列不为空，那么要利用调度策略，看时候能够和正在该块设备上排队的读写请求和二为一了。这里有一个很恰当的比方：当我们去饭店吃饭的时候，如果你要点的菜如果和师傅正在炒或者准备炒的菜一样的话，炒菜师傅会把两个人点的菜一块炒，特别是学校的食堂，每到吃饭高峰期，人很多，因此，学生们一般都会问服务员，下面要做的是什么菜，如果要节省时间的话，就要师傅下面要炒的菜了。在这里，磁盘的调度原理就是这个样子，貌似很简单哇。其实，有些时候，我们可能并不需要一个请求队列，比如，将来计算机的磁盘全部是SSD了，不再用机械磁盘了，都是电读写的，那么这个IO调度说不定就要被废除了。然后，也就不再需要请求队列了。一个请求到了，然后马上就发送到驱动程序，驱动程序想设备发送命令，读取数据。而在Linux的内核中，已经考虑到这一点了，如果进程进行同步IO的话，就直接启动驱动程序进行IO读写了（请参考代码段一）。
前面说到，将读写请求挂载在块设备的请求队列时，如果不为空的话，会看能否进行IO调度，不能调度的话，会向块设备请求队列插入一个请求。然后进程的任务就完成了。如果插入请求的时候，发现这个队列上的请求非常多，那么怎么办呢？进程就会主动的启动磁盘IO让这些请求队列赶紧执行(请参考代码片段二)。
上面设计到的进程启动磁盘IO，都算是主动的。除了主动的时候，还有被动的情况。当进程将请求挂载在块设备请求队列的时候，它是要用其中的数据的。什么时候用呢？该用的时候就用呀，不过用的时候，会检测相关的数据是否被读出了，如果没有读出，那么进程就被阻塞，然后启动磁盘IO(请参考代码片段三)。这一点在Linux2.6的内核中稍微进行了改进，设置了一个request数量阈值，如果大于这个阈值，那么就启动磁盘IO。
在Linux2.6的内核中，还增加了一个启动IO磁盘的时机，即，读写请求被插入到某个块设备的请求队列时，设置了一个定时器，保证在某个时间点之内，一定要启动磁盘IO。
启动磁盘IO后，数据怎么读出就跟进程没什么关系了。进程在使用的时候，就会查看它要用的buffer缓冲区是否locked，如果否，就说明已经读好了，如果是，那么就继续启动磁盘然后等待(代码片段三)。
以上基本上就分析完了。在2.6的内核中，在request和buffer head中又加了一个bio，不过仅仅加了个bio并不影响理解。另外，单单看块设备驱动，并不能够解决读写请求发送到块设备请求队列，然后块设备又怎样的把读写的数据读入到buffer中。当然了，在这一个南大富士通的赵磊大牛写过一个系列的文章“写一个块设备驱动”，一共120页。对我的帮助还是蛮大，当初凌晨看到2点半，然后又加上一个上午，基本上算是一口气看完了。写得不错，希望对块设备驱动有兴趣的同学，可以google一下，看看。



注：本文还非常naive，错误难免，如果发现，请批评指正。



附件：参考2.4.31内核
代码片段一:
         submit_bh->__make_request
1000 static int __make_request(request_queue_t * q, int rw,
1001                   struct buffer_head * bh)
1002 {
1003     unsigned int sector, count, sync;
1004     int max_segments = MAX_SEGMENTS;
1005     struct request * req, *freereq = NULL;
1006     int rw_ahead, max_sectors, el_ret;
1007     struct list_head *head, *insert_here;
1008     int latency;
1009     elevator_t *elevator = &q->elevator;
1010     int should_wake = 0;
1011
1012     count = bh->b_size >> 9;
1013     sector = bh->b_rsector;
1014     sync = test_and_clear_bit(BH_Sync, &bh->b_state);
1015
.。。。。。。。。。。。。。。。。。。。。。。。。。
1176 out:
1177     if (freereq)
1178         blkdev_release_request(freereq);
1179     if (should_wake)
1180         get_request_wait_wakeup(q, rw);
1181     if (sync)
1182         __generic_unplug_device(q);//进程发起启动磁盘IO
1183     spin_unlock_irq(&io_request_lock);
1184     return 0;
1185 end_io:
1186     bh->b_end_io(bh, test_bit(BH_Uptodate, &bh->b_state));
1187     return 0;
1188 }
代码片段二：
__make_request->__get_request_wait
 643 static struct request *__get_request_wait(request_queue_t *q, int rw)
 644 {             
 645     register struct request *rq;
 646     DECLARE_WAITQUEUE(wait, current);
 647
 648     add_wait_queue_exclusive(&q->wait_for_requests, &wait);
 649
 650     do {
 651         set_current_state(TASK_UNINTERRUPTIBLE);
 652         spin_lock_irq(&io_request_lock);
 653         if (blk_oversized_queue(q) || q->rq.count == 0) {
 654             __generic_unplug_device(q);//进程发起启动磁盘IO
 655             spin_unlock_irq(&io_request_lock);
 656             schedule();
 657             spin_lock_irq(&io_request_lock);
 658         }
 659         rq = get_request(q, rw);
 660         spin_unlock_irq(&io_request_lock);
 661     } while (rq == NULL);
 662     remove_wait_queue(&q->wait_for_requests, &wait);
 663     current->state = TASK_RUNNING;
 664
 665     return rq;
 666 }
 667
代码片段三：
 180 /* 
 181  * Note that the real wait_on_buffer() is an inline function that checks
 182  * that the buffer is locked before calling this, so that unnecessary disk
 183  * unplugging does not occur.
 184  */
 185 void __wait_on_buffer(struct buffer_head * bh)
 186 {
 187     struct task_struct *tsk = current;
 188     DECLARE_WAITQUEUE(wait, tsk);
 189
 190     get_bh(bh);
 191     add_wait_queue(&bh->b_wait, &wait);
 192     do {
 193         set_task_state(tsk, TASK_UNINTERRUPTIBLE);
 194         if (!buffer_locked(bh))
 195             break;
 196         /*
 197          * We must read tq_disk in TQ_ACTIVE after the
 198          * add_wait_queue effect is visible to other cpus.
 199          * We could unplug some line above it wouldn't matter
 200          * but we can't do that right after add_wait_queue
 201          * without an smp_mb() in between because spin_unlock
 202          * has inclusive semantics.
 203          * Doing it here is the most efficient place so we
 204          * don't do a suprious unplug if we get a racy
 205          * wakeup that make buffer_locked to return 0, and
 206          * doing it here avoids an explicit smp_mb() we
 207          * rely on the implicit one in set_task_state.
 208          */
 209         run_task_queue(&tq_disk);
 210         schedule();
 211     } while (buffer_locked(bh));
 212     tsk->state = TASK_RUNNING;
 213     remove_wait_queue(&bh->b_wait, &wait);
 214     put_bh(bh);
 215 }
__wait_on_buffer->run_task_queue
119 static inline void run_task_queue(task_queue *list)
120 {   
121     if (TQ_ACTIVE(*list))
122         __run_task_queue(list);
123 }
__wait_on_buffer->run_task_queue->__run_task_queue
334 void __run_task_queue(task_queue *list)
335 {
336     struct list_head head, *next;
337     unsigned long flags;
338
339     spin_lock_irqsave(&tqueue_lock, flags);
340     list_add(&head, list);
341     list_del_init(list);
342     spin_unlock_irqrestore(&tqueue_lock, flags);
343
344     next = head.next;
345     while (next != &head) {
346         void (*f) (void *);
347         struct tq_struct *p;
348         void *data;
349
350         p = list_entry(next, struct tq_struct, list);
351         next = next->next;
352         f = p->routine;
353         data = p->data;
354         wmb();
355         p->sync = 0;
356         if (f)
357             f(data);//这里对于普通的磁盘，就是generic_unplug_device，和代码片段一以及二是一个启动IO操作，
358         //其实这个函数还是包装了一下，最直接的是q->request_fn
359     }
360 }  



参考：
1.《Linux内核源码情景分析(下册)》,第八章，设备驱动
2.《深入Linux内核架构》，第六章，设备驱动程序
3.《写一个块设备驱动》，赵磊

评论

发表评论

此博客中的热门博文

Linux/ARM Page Table Entry 属性设置分析

图片
注：该博文写的比较凌乱，需要以后再修改。 Linux 的页表项总体可以划分为两部分，一部分是物理映射地址，另一部分是对物理地址对应的访问属性。在Linux/ARM的Kernel中，为各式各样的内存属性与定义了一下条目 ：   198 static struct mem_type mem_types[] = {  199         [MT_DEVICE] = {           /* Strongly ordered / ARMv6 shared device */  200                 .prot_pte       = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |  201                                   L_PTE_SHARED,  202                 .prot_l1        = PMD_TYPE_TABLE,  203                 .prot_sect      = PROT_SECT_DEVICE | PMD_SECT_S,  204                 .domain         = DOMAIN_IO,  205     ...
阅读全文

由RFE指令引发的一串故事

图片
前段时间,我们在bring up一块Cortex-A5主控的芯片时,发现在跑FreeRTOS时, 系统总是crash. 通过GDB定位到一旦RFE指令执行结束后,系统便进入data abort mode. <图一> 一旦执行RFE便进入data abort <图二>， FreeRTOS中RFE相关代码片段 RFE指令如其字面含义, return from exception. 它的主要作用是: 从栈中弹出值分别赋值给cpsr和pc. 这条指令在恢复现场时,具有不可替代的作用(如果用其他指令来代替同样的功能, 自然就污染其他寄存器了). RFE指令在ARM v7 spec中的伪码： <图三>，RFE指令的伪码 曾经一度怀疑是Cortex-A5的errata，但是CPU指令级别的仿真测试对于RFE指令是没有问题的。而且，之前在FPGA上做预开发的时候，在FPGA平台上也没有发现此类问题。所以，一度陷入到困局中，没有思路。 如果整个FreeRTOS来让SOC仿真，那么仿真的时间会比较久，因此我们写了下面一段比较小的代码来进行仿真测试。但是仿真下来并没有发现问题。 _start:     ldr r0, =vectors     mcr p15, 0, r0, c12, c0, 0   // PLD Capablity     mrc p15, 0, r0, c0, c2, 2 //MAIN IDR     mrc p15, 0, r0, c0, c0, 0 // CCSIDR     mrc p15, 1, r0, c0, c0, 0     cps #0x17     ldr r0, =0x30009000     str r0, [r0]     ldr r0, =0x10009000     mov sp, r0     cps #0x1f     ldr r0, =0x10008000     mov sp, r0     mrs r0...
阅读全文

ARM Linux 如何模拟X86 PTE中的Present Young和Dirty标志位

图片
注：本文是参考Kernel的代码并加上个人揣测，欢迎指正 在 X86 MMU Page table entry 中，有三个标志位在ARM 的MMU硬件所规定的Page table entry中不提供。这三个标志位的作用如下： PTE_DIRTY的作用：CPU在写操作的时候，处理器会将改位置位。说明对应的页被写过，是脏的。 PTE_YOUNG 的作用是：MMU 寻址是将该标志置位（在换出的时候，如果此标志位被置位，说明该地址刚刚被使用过，暂时不换出此 pte 对应的页，同时清除该标志位）。 PTE_PRESENT 的作用是： MMU 在访问 PTE 的时候，若 PTE_PRESENT 为 0 ，则将地址放在CR2寄存器中，同时触发Pagefault异常。 下图抓自：《Linux内核情景分析》 由于 Linux 最早是 build 在 X86 平台上的，因此移植到 ARM 后，也需要遵从 X86 的内存管理框架，模拟 ARM MMU 没有提供的 PTE_PRESENT ， PTE_YOUNG 和 PTE_WRITE 。 下面的分析，参考了arch/arm/include/asm/pgtable-2level.h中的注释 Q: 如何模拟 PTE_ DIRTY  ? A: ARM Linux 是通过 dirty 去标识某个页是否是可以 PTE_WRITE 的。 对于新分配的页，如果 Linux 版本的 PTE 没有 dirty 标识，对其进行写操作，会触发 MMU 异常。该异常会被 handle_pte_fault 处理 。 Q: 如何模拟 PTE_YOUNG? A: 这个 PTE_YOUNG 在内存被分配的时候置上，当解除映射的时候，将清掉该位。如果 Linux 版本的 PTE 的 young 位被清除了， MMU 使用的 PTE 版本的value是要清除的，但 TLB 并不刷新。 Q: 如何模拟 present ： A: ARM 的 MMU 在访问的时候，不像 X86 的 MMU 那样 ( 只要看到 *pte 为 0 ，就判断该页压根没有被加载到内存中；若 *pte 不为 0 ， PTE_PRESENT 位为 0 ，就能判断该被 swap out ...
阅读全文