---恢复内容开始---
今天查看iotop的原理，竟然发现了IO优先级一说，IO是block层cfs调度器中的概念
block层也有一个类似于CPU的调度算法
对进程分成三个级别：RT，BE，IDLE
其中，RT就是最高优先级的调度，类似与CPU调度中的RT调度，当有RT进程在的时候，其他的进程不会享受到磁盘的带宽；
BE：相当于CPU中的cfs调度器，可以保证公平高效地让进程共享IO资源；
IDLE：就是CPU中的最高一级的调度器了，当没有RT和BE的进程在的时候，才会让IDLE策略的进程去使用IO资源；
//-------------
通用块层和电梯调度层的区别【】
目前内核中的算法叫做CFQ，试图为所有进程提供一个完全公平的调度环境，以此保证每个进程的IO资源的占用是公平的，同时也设计了进程级别的优先级调度，在这里我们只需要知道，时间片分好了，优先级调好了，block层肯定能给所有的进程一个公平的IO资源占用（实现进程级别的IO资源按照权重分配）。
blkio中的cgroup资源的划分就是在cfq的基础上做的。所以如果想要使用权重比例分配，应该先确认对应的磁盘使用的是cfq调度算法.
cfq是比较好的IO调度算法，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适用，尤其在IO压力集中在某些进程上的场景。因为这些场景我们需要满足某几个进程的执行速度，而不是让全部进程公平想用IO的带宽。
deadline更适应这样的场景的解决方案。deadline有四个通用的
//-----------
调度器：
block层可
在哪里更新iops的值
blk_throtl_bio
generic_make_request_check --> blkcg_bio_issue_check --> blk_throtl_bio
在哪里更新IO信息？add_acct_request
blk_queue_bio --> add_acct_request 【IO经过层层检查并且已经进入了某个等待队列】
各种方法各有利弊，cfq是一种比较通用的调度算法，是一种以进程为出发点考虑的算法，以尽量保证大家的公平。deadline只有当IO请求达到一定期限的时候才进行调度，因此非常适合业务比较单一且IO压力比较重的业务。
当然，IO贮存是以分区为单位，还是以磁盘为单位呢？
---恢复内容结束---
今天查看iotop的原理，竟然发现了IO优先级一说，IO是block层cfs调度器中的概念
block层也有一个类似于CPU的调度算法
对进程分成三个级别：RT，BE，IDLE
其中，RT就是最高优先级的调度，类似与CPU调度中的RT调度，当有RT进程在的时候，其他的进程不会享受到磁盘的带宽；
BE：相当于CPU中的cfs调度器，可以保证公平高效地让进程共享IO资源；
IDLE：就是CPU中的最高一级的调度器了，当没有RT和BE的进程在的时候，才会让IDLE策略的进程去使用IO资源；
//-------------
通用块层和电梯调度层的区别【】
目前内核中的算法叫做CFQ，试图为所有进程提供一个完全公平的调度环境，以此保证每个进程的IO资源的占用是公平的，同时也设计了进程级别的优先级调度，在这里我们只需要知道，时间片分好了，优先级调好了，block层肯定能给所有的进程一个公平的IO资源占用（实现进程级别的IO资源按照权重分配）。
blkio中的cgroup资源的划分就是在cfq的基础上做的。所以如果想要使用权重比例分配，应该先确认对应的磁盘使用的是cfq调度算法.
cfq是比较好的IO调度算法，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适用，尤其在IO压力集中在某些进程上的场景。因为这些场景我们需要满足某几个进程的执行速度，而不是让全部进程公平想用IO的带宽。
deadline更适应这样的场景的解决方案。deadline有四个通用的
//-----------
调度器：
block层可
在哪里更新iops的值
blk_throtl_bio
generic_make_request_check --> blkcg_bio_issue_check --> blk_throtl_bio
在哪里更新IO信息？add_acct_request
blk_queue_bio --> add_acct_request 【IO经过层层检查并且已经进入了某个等待队列】
各种方法各有利弊，cfq是一种比较通用的调度算法，是一种以进程为出发点考虑的算法，以尽量保证大家的公平。deadline只有当IO请求达到一定期限的时候才进行调度，因此非常适合业务比较单一且IO压力比较重的业务。
当然，IO贮存是以分区为单位，还是以磁盘为单位呢？
---恢复内容开始---
今天查看iotop的原理，竟然发现了IO优先级一说，IO是block层cfs调度器中的概念
block层也有一个类似于CPU的调度算法
对进程分成三个级别：RT，BE，IDLE
其中，RT就是最高优先级的调度，类似与CPU调度中的RT调度，当有RT进程在的时候，其他的进程不会享受到磁盘的带宽；
BE：相当于CPU中的cfs调度器，可以保证公平高效地让进程共享IO资源；
IDLE：就是CPU中的最高一级的调度器了，当没有RT和BE的进程在的时候，才会让IDLE策略的进程去使用IO资源；
//-------------
通用块层和电梯调度层的区别【】
目前内核中的算法叫做CFQ，试图为所有进程提供一个完全公平的调度环境，以此保证每个进程的IO资源的占用是公平的，同时也设计了进程级别的优先级调度，在这里我们只需要知道，时间片分好了，优先级调好了，block层肯定能给所有的进程一个公平的IO资源占用（实现进程级别的IO资源按照权重分配）。
blkio中的cgroup资源的划分就是在cfq的基础上做的。所以如果想要使用权重比例分配，应该先确认对应的磁盘使用的是cfq调度算法.
cfq是比较好的IO调度算法，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适用，尤其在IO压力集中在某些进程上的场景。因为这些场景我们需要满足某几个进程的执行速度，而不是让全部进程公平想用IO的带宽。
deadline更适应这样的场景的解决方案。deadline有四个通用的
//-----------
调度器：
block层可
在哪里更新iops的值
blk_throtl_bio
generic_make_request_check --> blkcg_bio_issue_check --> blk_throtl_bio
在哪里更新IO信息？add_acct_request
blk_queue_bio --> add_acct_request 【IO经过层层检查并且已经进入了某个等待队列】
各种方法各有利弊，cfq是一种比较通用的调度算法，是一种以进程为出发点考虑的算法，以尽量保证大家的公平。deadline只有当IO请求达到一定期限的时候才进行调度，因此非常适合业务比较单一且IO压力比较重的业务。
当然，IO贮存是以分区为单位，还是以磁盘为单位呢？
---恢复内容结束---
今天查看iotop的原理，竟然发现了IO优先级一说，IO是block层cfs调度器中的概念
block层也有一个类似于CPU的调度算法
对进程分成三个级别：RT，BE，IDLE
其中，RT就是最高优先级的调度，类似与CPU调度中的RT调度，当有RT进程在的时候，其他的进程不会享受到磁盘的带宽；
BE：相当于CPU中的cfs调度器，可以保证公平高效地让进程共享IO资源；
IDLE：就是CPU中的最高一级的调度器了，当没有RT和BE的进程在的时候，才会让IDLE策略的进程去使用IO资源；
//-------------
通用块层和电梯调度层的区别【】
目前内核中的算法叫做CFQ，试图为所有进程提供一个完全公平的调度环境，以此保证每个进程的IO资源的占用是公平的，同时也设计了进程级别的优先级调度，在这里我们只需要知道，时间片分好了，优先级调好了，block层肯定能给所有的进程一个公平的IO资源占用（实现进程级别的IO资源按照权重分配）。
blkio中的cgroup资源的划分就是在cfq的基础上做的。所以如果想要使用权重比例分配，应该先确认对应的磁盘使用的是cfq调度算法.
cfq是比较好的IO调度算法，对桌面用户也是比较好的选择。但是对于很多IO压力较大的场景就并不是很适用，尤其在IO压力集中在某些进程上的场景。因为这些场景我们需要满足某几个进程的执行速度，而不是让全部进程公平想用IO的带宽。
deadline更适应这样的场景的解决方案。deadline有四个通用的
//-----------
调度器：
block层可
在哪里更新iops的值
blk_throtl_bio
generic_make_request_check --> blkcg_bio_issue_check --> blk_throtl_bio
在哪里更新IO信息？add_acct_request
blk_queue_bio --> add_acct_request 【IO经过层层检查并且已经进入了某个等待队列】
各种方法各有利弊，cfq是一种比较通用的调度算法，是一种以进程为出发点考虑的算法，以尽量保证大家的公平。deadline只有当IO请求达到一定期限的时候才进行调度，因此非常适合业务比较单一且IO压力比较重的业务。
当然，IO贮存是以分区为单位，还是以磁盘为单位呢？
///-------->
内核
每次同步的读操作都会触发这样的操作，在这个读操作中会触发：__blk_run_queue_uncond，干哈子啊这是，也就是说我一个读的操作，要刷回目前device等待队列里的所有的IO！天啊，如果系统中此时有等待的IO，那么这个时候要刷回系统中所有的IO？
【突然有个想法：其实对于block来说，每个进程都是同步！无论是同步读，调用sync/directIO，还是kworker异步的进程，都是一个进程带着IO进入设备的等待队列，对于上面这些线程来说，都是同步的】
#0 scsi_dispatch_cmd (cmd=0xffff88007d351380) at drivers/scsi/scsi_lib.c:1578
#1 0xffffffff814ba3ae in scsi_request_fn (q=0xffff88007c4d0000) at drivers/scsi/scsi_lib.c:1769
#2 0xffffffff813521a3 in __blk_run_queue_uncond (q=<optimized out>) at block/blk-core.c:325
#3 __blk_run_queue (q=0xffff88007c4d0000) at block/blk-core.c:343
#4 0xffffffff81356738 in blk_queue_bio (q=0xffff88007c4d0000, bio=0xffff88007c4dfb00) at block/blk-core.c:1799
#5 0xffffffff81354900 in generic_make_request (bio=0xffff88007c4dfb00) at block/blk-core.c:2062
#6 0xffffffff81354a1e in submit_bio (bio=0xffff88007d351380) at block/blk-core.c:2122
#7 0xffffffff811b35e4 in submit_bh_wbc (op=<optimized out>, op_flags=2087354696, bh=0xffff88007d351380, bio_flags=18446612134400221448,
wbc=<optimized out>) at fs/buffer.c:3101
#8 0xffffffff811b4115 in submit_bh (bh=<optimized out>, op_flags=<optimized out>, op=<optimized out>) at fs/buffer.c:3114
#9 ll_rw_block (op=0, op_flags=48, nr=<optimized out>, bhs=<optimized out>) at fs/buffer.c:3164
#10 0xffffffff811fd5f8 in ext4_bread (handle=<optimized out>, inode=<optimized out>, block=<optimized out>, map_flags=<optimized out>)
at fs/ext4/inode.c:998
#11 0xffffffff81206834 in __ext4_read_dirblock (inode=0xffff88007c14f120, block=0, type=DIRENT, func=<optimized out>, line=960)
at fs/ext4/namei.c:99
#12 0xffffffff81207177 in htree_dirblock_to_tree (dir_file=<optimized out>, dir=0xffff88007c14f120, block=<optimized out>,
hinfo=0xffffc9000025bd90, start_hash=<optimized out>, start_minor_hash=<optimized out>) at fs/ext4/namei.c:960
#13 0xffffffff81207f86 in ext4_htree_fill_tree (dir_file=0xffff88007d351380, start_hash=2087354696, start_minor_hash=<optimized out>,
next_hash=<optimized out>) at fs/ext4/namei.c:1079
#14 0xffffffff811f5e40 in ext4_dx_readdir (ctx=<optimized out>, file=<optimized out>) at fs/ext4/dir.c:574
#15 ext4_readdir (file=0xffff88007c4df900, ctx=0xffffc9000025bef0) at fs/ext4/dir.c:121
#16 0xffffffff81192339 in iterate_dir (file=0xffff88007c4df900, ctx=0xffffc9000025bef0) at fs/readdir.c:50
#17 0xffffffff811927c8 in SYSC_getdents (count=<optimized out>, dirent=<optimized out>, fd=<optimized out>) at fs/readdir.c:230
#18 SyS_getdents (fd=<optimized out>, dirent=<optimized out>, count=32768) at fs/readdir.c:211
#19 0xffffffff8186bd60 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:209
#20 0x00007f9cc87a4698 in ?? ()
什么情况下已经合并到电梯里面了，但是却并没有下发，竟然给了合并的机会。感觉都是直接下发去了. plug只是很少的情况吧：
[昨晚睡觉之前想出来的答案：非plugin的进程，每个进程来了之后，就是会直接通过run_blk_queue下去刷自己的包，在函数blk_peek_request中取request去下发，但是这个时候scsi的处理速度也不是一定，所以会有大量的包在堆积在电梯中的情况，因为去取包的时候是加锁的吗？接着朝下看]
spin_unlock_irq(q->queue_lock);
上面这个锁用的太恶心了，因为散落在各处的 lock VS unlock ，也就是说在进程A去刷自己的东西的时候，进程B也可能去刷掉，进程Ｃ也有可能把自己的一个ｂｉｏ插入到某一个队列中去，好了，那现在进程可以排队这个没有疑问了，那么新的疑问是：我进程Ａ是一个读的进程，那么我通过__run_blk_queue方法进入到这个函数中去了，然后这个函数是一个循环，他要刷掉所有的要等待的ＩＯ才算数，我去，真的是这个样子吗？并且这样也不合理呀，我只要保证我的读下去了不就行了，为什么要保证别的读，甚至是别的写的ＩＯ要下去呀，