Linux内核之IO4：块I/O流程与I/O调度器

爱被打了一巴掌 2022-12-01 14:24 75阅读 0赞

## **1一个块IO的一生** ##

从page cache到bio到request

当APP打开一个文件，内核为文件维护一个pagecache(磁盘的一个副本)；

读写文件时如果page cache命中，只会读写内存不操作磁盘；没有命中，才操作磁盘。

在内核用file结构体表示，可见其包含一个inode结构体，一个地址空间；

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a6IK334b-1598522185421)(media/b4fc3b664828c2ac91bb39d180b66983.png)\]][img-a6IK334b-1598522185421_media_b4fc3b664828c2ac91bb39d180b66983.png]

相关的几个结构体在内核对应关系如下：

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UT4HJAL5-1598522185423)(media/7368f2d6d172d382c9caeefe23478bd4.png)\]][img-UT4HJAL5-1598522185423_media_7368f2d6d172d382c9caeefe23478bd4.png]

可见，当多个进程同时打开同一个文件时，不同的file结构体对应同一个inode和同一个地址空间，地址空间是由一颗radix  
tree维护(即pagecache)，读写文件时，查看对应内存页在page  
cache中是否命中，若命中直接从内存空间读写；若不命中，申请一个内存页，从磁盘读入数据，挂到page  
cache的radix tree中。

另外，page cache与磁盘的同步由地址空间操作函数readpage/writepage完成

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EXZk9BPi-1598522185425)(media/5055642cae44e45b9a2fea743868e997.png)\]][img-EXZk9BPi-1598522185425_media_5055642cae44e45b9a2fea743868e997.png]

对磁盘访问，有两种方法：

a.裸磁盘直接访问；

b.通过文件系统访问；

它们在内核page cached对应关系如下：

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M4oitnRH-1598522185426)(media/a9e74e815160bc6a75691febc7bbc3d2.png)\]][img-M4oitnRH-1598522185426_media_a9e74e815160bc6a75691febc7bbc3d2.png]

一个address\_space对应一个inode。

**free命令统计的buffer/cached，只是统计上的区别；**

buffer=操作裸分区的地址空间+文件系统的元数据地址空间；

cached=文件系统的地址空间(page cached)缓存；

但是对同一个磁盘，裸磁盘和文件系统两种方式同时操作的时候，同一个数据块会被映射到不同的address\_space，会产生同步的问题；

在用dd的时候，最好不要操作文件系统数据。

## **2 O\_DIRECT和O\_SYNC** ##

直接操作裸磁盘分区用O\_DIRECT，内核没有任何cache，直接操作磁盘；用户可以根据数据特点，在用户空间做cache。O\_DIRECT申请内存要用posix\_memalign接口；

而O\_SYNC依然通过page cache，但是会立即写入同步磁盘；

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mtSzm0BJ-1598522185428)(media/6e8d0b90b7fa999a106fd8229b813092.png)\]][img-mtSzm0BJ-1598522185428_media_6e8d0b90b7fa999a106fd8229b813092.png]

App通过page cache访问文件和直接操作裸磁盘的模型，与CPU通过cache访问内存和DMA直接访问内存的模型非常类似；

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lwGr1E7P-1598522185429)(media/d346563e1060e300aceab7c119f219cd.png)\]][img-lwGr1E7P-1598522185429_media_d346563e1060e300aceab7c119f219cd.png]

这里page cache是内存，file是磁盘分区数据块；

当有一个进程启用O\_DIRECT模式，其他进程最好也用O\_DIRECT；

## **3 BIO 流程blktrace** ##

对于一个pagecache地址空间，指向的是page页，文件系统ext4读取inode，将page转化为磁盘数据块，变成BIO请求；

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P3FBqCon-1598522185432)(media/73ae7dac9947707be7c90218bb7e333e.png)\]][img-P3FBqCon-1598522185432_media_73ae7dac9947707be7c90218bb7e333e.png]

BIO最终要转化成request，然后request被块设备驱动程序调用完成；

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZL6VsJmW-1598522185433)(media/c3b2b4f843a5be585949b5a0bfe093c3.png)\]][img-ZL6VsJmW-1598522185433_media_c3b2b4f843a5be585949b5a0bfe093c3.png]

### Bio经过三个队列变成request，三进三出 ###

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ejPpimal-1598522185434)(media/cec4015ac03ce1c79672370beb5e496f.png)\]][img-ejPpimal-1598522185434_media_cec4015ac03ce1c79672370beb5e496f.png]

#### **step1:原地蓄势** ####

把bio转化为request，把request放入进程本进程的**plug队列**；蓄势多个request后，再进行泄洪。

可能合并相邻bio为一个request；

Bio数量>=request数量；

多个进程，泄洪request到电梯；

#### **step2.电梯排序** ####

进程本地的plug队列的request进入到**电梯队列**，进行再次的合并、排序，执行QoS的排队，之后按照QoS的结果，分发给**dispatch队列**。电梯内部的实现，可以有各种各样的队列。

比如两个进程需要读邻近的数据块，可以合并为一个request

电梯调度层可以做QoS，设定进程访问IO的优先级；

#### **step3.分发执行dispatch** ####

电梯分发的request，被设备驱动的request\_fn()挨个取出来，派发真正的硬件读写命令到硬盘。这个分发的队列，一般就是我们在块设备驱动里面见到的request\_queue了。request\_queue完成真正的硬件操作；

## 工具ftrace ##

do.sh

#!/bin/bash
    
    debugfs=/sys/kernel/debug
    echo nop > $debugfs/tracing/current_tracer
    echo 0 > $debugfs/tracing/tracing_on
    echo `pidof read` > $debugfs/tracing/set_ftrace_pid
    echo function_graph > $debugfs/tracing/current_tracer
    echo vfs_read > $debugfs/tracing/set_graph_function
    echo 1 > $debugfs/tracing/tracing_on

执行./read读文件

查看trace过程

sudo cat /sys/kernel/debug/tracing/trace > t.txt

用VIM查看t.txt，用.funcgrahp.vim插件打开可以合并/展开对应函数调用

vim -S ~/.funcgrahp.vim

## **4 IO调度算法，CFQ和ionice** ##

查看当前系统的IO调度算法

(base) leon\@pc:/sys/block/sda/queue\$ cat scheduler
    
    noop deadline [cfq]

修改调度算法:

sudo echo cfg > scheduler

CFQ调度算法:类似进程调度的CFS算法

ionice –help
    
    ionice –c 2 –n 0 dd if=/dev/sda of=/dev/null &  //设置nice值=0
    
    ionice –c 2 –n 8 dd if=/dev/sda of=/dev/null &  //设置nice值=8

iotop查看IO读写速度，有明显差异

改成deadline策略

echo deadline > scheduler

此时尽管优先级不同，但两个进程IO速度相近了；

## 5 cgroup与IO ##

cd /sys/fs/cgroup/blkio

### **a.创建群组A,B** ###

Mkdir A;makedir B

cat blkiolweight //默认是500

分别把两个进程放到A和B执行

cgexec -g blkio:A dd if=/dev/sda of=/dev/null iflag=direct &

cgexec -g blkio:B dd if=/dev/sda of=/dev/null iflag=direct &

查看io占用iotop

默认是相近

### **b.修改群权重** ###

echo 50 > blkio.weight

两个进程优先级一样，但IO速度差别很大；

**c.cgroup还可以控制阀门，限制最大读速度：**

8：0磁盘的主次设备号

echo "8:0 1048576" > /sys/fs/cgroup/blkio/A/blkio.throttle.read_bps_device

带cache读写，这里的限速不起作用；direct方式才生效；

cgroup v2版本支持带cache限速

## 6 IO性能调试：iotop, iostat ##

blktrace跟踪硬盘的各个读写点

blktrace –d /dev/sda –o - |blkparse –I –

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-U88N0m26-1598522185436)(media/655ca2c024d9e7389804957ba318e5c1.png)\]][img-U88N0m26-1598522185436_media_655ca2c024d9e7389804957ba318e5c1.png]

dd if=main.c of=t.txt oflag=sync
    
    debugfs –R ‘ickeck xxxx’ /dev/sda1
    
    debugfs –R ‘nckeck inode’ /dev/sda1
    
    blkcat /dev/sda1 xxx

[img-a6IK334b-1598522185421_media_b4fc3b664828c2ac91bb39d180b66983.png]: /images/20221123/c7321160183b4495b7186a68fd4ca9c5.png
[img-UT4HJAL5-1598522185423_media_7368f2d6d172d382c9caeefe23478bd4.png]: /images/20221123/a51297cac94a4e9280039acc4784d542.png
[img-EXZk9BPi-1598522185425_media_5055642cae44e45b9a2fea743868e997.png]: /images/20221123/575bbcbc3b474413a70aa7192fd3b895.png
[img-M4oitnRH-1598522185426_media_a9e74e815160bc6a75691febc7bbc3d2.png]: /images/20221123/dbb468ae5c8240b08c2d40f76db1ea9a.png
[img-mtSzm0BJ-1598522185428_media_6e8d0b90b7fa999a106fd8229b813092.png]: /images/20221123/4ea2401e0d5d4683bd8e6c47aa0e6910.png
[img-lwGr1E7P-1598522185429_media_d346563e1060e300aceab7c119f219cd.png]: /images/20221123/3ed0f54cc84349958969a2da7b9db458.png
[img-P3FBqCon-1598522185432_media_73ae7dac9947707be7c90218bb7e333e.png]: /images/20221123/ac864e14293043bfb2b2d92f1ff26944.png
[img-ZL6VsJmW-1598522185433_media_c3b2b4f843a5be585949b5a0bfe093c3.png]: /images/20221123/f6b24c7320d94eb1b62db2d4e0d75c6b.png
[img-ejPpimal-1598522185434_media_cec4015ac03ce1c79672370beb5e496f.png]: /images/20221123/009ed89dc45b4548978d02f4db51c64d.png
[img-U88N0m26-1598522185436_media_655ca2c024d9e7389804957ba318e5c1.png]: /images/20221123/9f586978d4594831b1e0d24171700d1c.png