cfq_tuning
==========
Author: yu peng
Date: 2012-07-27 19:58:01 HKT
Table of Contents
=================
1 概要
2 back_seek_max 和 back_seek_penalty
3 slice_async，slice_sync，和 slice_async_rq
4 low_latency
5 quantum
6 fifo_expire_async 和 fifo_expire_sync
7 slice_idle
8 group_idle
9 group_isolation
1 概要
-------
以rhel6系统所用的2.6.32内核为基础，分析cfq io调度器的tuning参数。
2 back_seek_max 和 back_seek_penalty
-------------------------------------
这两个参数是用来确定，对于给定的两个IO，哪个更适合作为“下一个”IO被
传送给设备。判定的方法就是谁距离磁头更近。磁头的位置就是上一次IO完成
的位置。比如磁头的位置last是sector 100。两个IO，io1的起始扇区号是105，
io2的起始扇区号是110那么，io1距离磁头更近，下一次要发送IO，就先发io1，
再发io2。
如果io1的起始扇区号是90，io2的起始扇区号是110呢？两个io距离磁头的距离
都是10，这时该如何选择呢？一般来说，把磁头向前移动（从扇区100向扇区
90移动）需要花费的时间要多一些，所以cfq倾向于选择向后移动（从扇区100
向扇区110移动）。
如果io1的起始扇区号是95，io2的起始扇区号是110呢？虽然io1在磁头的前面，
io2在磁头的后面，但io1距离磁头更近一些，这时该如何选择呢？具体的判断
方法就用到了back_seek_penalty。比如io1在磁头的前面，距离磁头的距离是
s1，io2在磁头的后面，距离磁头的距离是s2，如果s1*back_seek_penalty小于
s2，就认为io1距离磁头比较近，否则，就认为io2距离磁头比较近。
如果io1在磁头的前面，而io2在磁头的后面，但io1距离磁头太远了，超过了
back_seek_max，那么无论io2是不是距离磁头更远，都选择io2。
3 slice_async，slice_sync，和 slice_async_rq
---------------------------------------------
每个进程发下来的IO都被分成三类：异步，同步，idle。cfq先处理所有进程
发下来的同步IO，然后处理所有进程发下来的异步IO,最后处理idle IO。进一
步的，同步和异步的IO又被分别分成了8个不同等级的优先级。同一个进程发
送下来的同步IO，都有同样的优先级，异步的也是如此。对于每个进程的IO，
都被组织到一个叫做cfq_queue的结构体中。对于一个进程发送下来的IO，所
有的同步IO有一个cfq_queue，所有的异步IO有另一个cfq_queue。cfq会给每
个cfq_queue都分配一个时间片。比如当一个进程的同步IO的时间片用完后，就
开始发送另一个进程的同步IO。时间片的大小由两个因素决定，一个是IO的优
先级，这是和进程的IO优先级相关的，如果进程没有设置IO优先级，就按照
nice值成正比计算出一个，另一个因素就是slice_async和slice_sync这两个
参数。如果这两个参数越大，那么所有异步和同步IO的时间片粒度就越大，反
之则粒度越小。对于异步IO，还有一个限制，如果在一个时间片内，已经发送
的异步IO总数大于slice_async_rq，那么也视为时间片到期。idle类型的IO没
有时间片，每次只发送一个。
注意，这里说的异步IO和linux内核提供的AIO机制是两码事，一点关系都没有。
一般来说，用户进程发送的读操作和设置direct标志的写操作都是sync类型的
IO，普通的写操作会写道cache里面，再由内核进程通过cache发送到IO调度器
的是async类型的IO。
4 low_latency
--------------
如果这个参数被设置了，那么当前面计算出的cfq_queue的时间片大于
low_latency时，会把时间片强行设置为low_latency。
5 quantum
----------
除了idle类型的IO是一个一个的放到块设备的queue里面之外，sync和async类
型的IO每次都是批量放入queue里面的。quantum就是一次批处理的数量。
6 fifo_expire_async 和 fifo_expire_sync
----------------------------------------
cfq对不同进程发下来的IO分时间片进行处理，但在处理同一个进程发下来的
IO时，采用与dead line类似的做法。尽量按照减小磁头移动的方式选择IO，
但如果有些IO等待的时间太久了的话，就转而处理这些等待太久的IO。
fifo_expire_async和fifo_expire_sync就是分别用来设置async类型IO和sync
类型IO的超时时间的。
7 slice_idle
-------------
在cfq中，最后被处理的IO是idle类型的IO，当调度器中已经没有任何的同步
或异步类型的IO，并且这种状况已经持续了slice_idle这么长的时间，那么
cfq就认为现在处于idle状态了，就发送一个idle类型的IO，然后再等待
slice_idle这么长的时间，如果还是没有其他IO，就再发送一个idle类型的IO。
补充一下，这个参数，以及所有本文中提到的和时间有关的参数，单位都是毫秒。
8 group_idle
-------------
我的理解，不一定准确：
当这个参数被设置之后，每当属于一个cgroup的进程的IO都提交完了，但时间
片还没有耗尽，那么不会马上提交属于另一个cgroup的IO，而是会等待
group_idle这么长的时间，如果在这个时间段内，该cgroup又有IO提交了进来，
那么就继续处理。
这个参数的引入是为了针对磁盘阵列或者固态硬盘这样的设备做优化用的，参
看这篇文章：
[http://lwn.net/Articles/395769/]
以及内核文档blkio-controller.txt中的描述：
CFQ sysfs tunable
=================
/sys/block/<disk>/queue/iosched/slice_idle
------------------------------------------
On a faster hardware CFQ can be slow, especially with sequential workload.
This happens because CFQ idles on a single queue and single queue might not
drive deeper request queue depths to keep the storage busy. In such scenarios
one can try setting slice_idle=0 and that would switch CFQ to IOPS
(IO operations per second) mode on NCQ supporting hardware.
That means CFQ will not idle between cfq queues of a cfq group and hence be
able to driver higher queue depth and achieve better throughput. That also
means that cfq provides fairness among groups in terms of IOPS and not in
terms of disk time.
/sys/block/<disk>/queue/iosched/group_idle
------------------------------------------
If one disables idling on individual cfq queues and cfq service trees by
setting slice_idle=0, group_idle kicks in. That means CFQ will still idle
on the group in an attempt to provide fairness among groups.
By default group_idle is same as slice_idle and does not do anything if
slice_idle is enabled.
One can experience an overall throughput drop if you have created multiple
groups and put applications in that group which are not driving enough
IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
on individual groups and throughput should improve.
What works
==========
- Currently only sync IO queues are support. All the buffered writes are
still system wide and not per group. Hence we will not see service
differentiation between buffered writes between groups.
在高速存储上，这样一组经验值可以获得较好的性能：
slice_idle = 0
quantum = 64
group_idle = 1
这些值在/sys/block/devicename/queue/iosched/中可以找到。
9 group_isolation
------------------
kernel document中有一个blkio-controller.txt文件，对这个参数做出了解释，
将其原文摘抄如下：
CFQ sysfs tunable
=================
/sys/block/<disk>/queue/iosched/group_isolation
If group_isolation=1, it provides stronger isolation between groups at the
expense of throughput. By default group_isolation is 1. In general that
means that if group_isolation=0, expect fairness for sequential workload
only. Set group_isolation=1 to see fairness for random IO workload also.
Generally CFQ will put random seeky workload in sync-noidle category. CFQ
will disable idling on these queues and it does a collective idling on group
of such queues. Generally these are slow moving queues and if there is a
sync-noidle service tree in each group, that group gets exclusive access to
disk for certain period. That means it will bring the throughput down if
group does not have enough IO to drive deeper queue depths and utilize disk
capacity to the fullest in the slice allocated to it. But the flip side is
that even a random reader should get better latencies and overall throughput
if there are lots of sequential readers/sync-idle workload running in the
system.
If group_isolation=0, then CFQ automatically moves all the random seeky queues
in the root group. That means there will be no service differentiation for
that kind of workload. This leads to better throughput as we do collective
idling on root sync-noidle tree.
我的理解，不一定准确：
cfq支持cgroup机制，可以区别对待属于不同cgroup的进程发下的io，给他们分
配不同的带宽。但这样会对效率造成比较大的影响。因为每个进程发送下来的读
写请求的位置可能差别很大，这样就会造成磁盘磁头来回的移动。所以，cfq提
供了这样一个参数，当group_isolation为0的时候，就把所有属于
SYNC_NOIDLE_WORKLOAD类型的cfq_queue都移动到root_group这个cgroup中。每
个进程都有几个它自己的cfq_queue，进程发送下来的IO，会根据IO的种类分别
放到不同的cfq_queue中去。从这个函数里我们可以看到怎么判断cfq_queue的种
类：
static enum wl_type_t cfqq_type(struct cfq_queue *cfqq)
{
if (!cfq_cfqq_sync(cfqq))
return ASYNC_WORKLOAD;
if (!cfq_cfqq_idle_window(cfqq))
return SYNC_NOIDLE_WORKLOAD;
return SYNC_WORKLOAD;
}
如果cfq_queue里面放的是同步的IO,那么它就是ASYNC_WORKLOAD类的，如果
cfq_queue里面放的不是idle类型的IO（优先级最低的一种IO，只在空闲时才处
理），那么它就是SYNC_NOIDLE_WORKLOAD类型的，否则（也就是idle类型的IO），它
就是SYNC_WORKLOAD类型的。
==========
Author: yu peng
Date: 2012-07-27 19:58:01 HKT
Table of Contents
=================
1 概要
2 back_seek_max 和 back_seek_penalty
3 slice_async，slice_sync，和 slice_async_rq
4 low_latency
5 quantum
6 fifo_expire_async 和 fifo_expire_sync
7 slice_idle
8 group_idle
9 group_isolation
1 概要
-------
以rhel6系统所用的2.6.32内核为基础，分析cfq io调度器的tuning参数。
2 back_seek_max 和 back_seek_penalty
-------------------------------------
这两个参数是用来确定，对于给定的两个IO，哪个更适合作为“下一个”IO被
传送给设备。判定的方法就是谁距离磁头更近。磁头的位置就是上一次IO完成
的位置。比如磁头的位置last是sector 100。两个IO，io1的起始扇区号是105，
io2的起始扇区号是110那么，io1距离磁头更近，下一次要发送IO，就先发io1，
再发io2。
如果io1的起始扇区号是90，io2的起始扇区号是110呢？两个io距离磁头的距离
都是10，这时该如何选择呢？一般来说，把磁头向前移动（从扇区100向扇区
90移动）需要花费的时间要多一些，所以cfq倾向于选择向后移动（从扇区100
向扇区110移动）。
如果io1的起始扇区号是95，io2的起始扇区号是110呢？虽然io1在磁头的前面，
io2在磁头的后面，但io1距离磁头更近一些，这时该如何选择呢？具体的判断
方法就用到了back_seek_penalty。比如io1在磁头的前面，距离磁头的距离是
s1，io2在磁头的后面，距离磁头的距离是s2，如果s1*back_seek_penalty小于
s2，就认为io1距离磁头比较近，否则，就认为io2距离磁头比较近。
如果io1在磁头的前面，而io2在磁头的后面，但io1距离磁头太远了，超过了
back_seek_max，那么无论io2是不是距离磁头更远，都选择io2。
3 slice_async，slice_sync，和 slice_async_rq
---------------------------------------------
每个进程发下来的IO都被分成三类：异步，同步，idle。cfq先处理所有进程
发下来的同步IO，然后处理所有进程发下来的异步IO,最后处理idle IO。进一
步的，同步和异步的IO又被分别分成了8个不同等级的优先级。同一个进程发
送下来的同步IO，都有同样的优先级，异步的也是如此。对于每个进程的IO，
都被组织到一个叫做cfq_queue的结构体中。对于一个进程发送下来的IO，所
有的同步IO有一个cfq_queue，所有的异步IO有另一个cfq_queue。cfq会给每
个cfq_queue都分配一个时间片。比如当一个进程的同步IO的时间片用完后，就
开始发送另一个进程的同步IO。时间片的大小由两个因素决定，一个是IO的优
先级，这是和进程的IO优先级相关的，如果进程没有设置IO优先级，就按照
nice值成正比计算出一个，另一个因素就是slice_async和slice_sync这两个
参数。如果这两个参数越大，那么所有异步和同步IO的时间片粒度就越大，反
之则粒度越小。对于异步IO，还有一个限制，如果在一个时间片内，已经发送
的异步IO总数大于slice_async_rq，那么也视为时间片到期。idle类型的IO没
有时间片，每次只发送一个。
注意，这里说的异步IO和linux内核提供的AIO机制是两码事，一点关系都没有。
一般来说，用户进程发送的读操作和设置direct标志的写操作都是sync类型的
IO，普通的写操作会写道cache里面，再由内核进程通过cache发送到IO调度器
的是async类型的IO。
4 low_latency
--------------
如果这个参数被设置了，那么当前面计算出的cfq_queue的时间片大于
low_latency时，会把时间片强行设置为low_latency。
5 quantum
----------
除了idle类型的IO是一个一个的放到块设备的queue里面之外，sync和async类
型的IO每次都是批量放入queue里面的。quantum就是一次批处理的数量。
6 fifo_expire_async 和 fifo_expire_sync
----------------------------------------
cfq对不同进程发下来的IO分时间片进行处理，但在处理同一个进程发下来的
IO时，采用与dead line类似的做法。尽量按照减小磁头移动的方式选择IO，
但如果有些IO等待的时间太久了的话，就转而处理这些等待太久的IO。
fifo_expire_async和fifo_expire_sync就是分别用来设置async类型IO和sync
类型IO的超时时间的。
7 slice_idle
-------------
在cfq中，最后被处理的IO是idle类型的IO，当调度器中已经没有任何的同步
或异步类型的IO，并且这种状况已经持续了slice_idle这么长的时间，那么
cfq就认为现在处于idle状态了，就发送一个idle类型的IO，然后再等待
slice_idle这么长的时间，如果还是没有其他IO，就再发送一个idle类型的IO。
补充一下，这个参数，以及所有本文中提到的和时间有关的参数，单位都是毫秒。
8 group_idle
-------------
我的理解，不一定准确：
当这个参数被设置之后，每当属于一个cgroup的进程的IO都提交完了，但时间
片还没有耗尽，那么不会马上提交属于另一个cgroup的IO，而是会等待
group_idle这么长的时间，如果在这个时间段内，该cgroup又有IO提交了进来，
那么就继续处理。
这个参数的引入是为了针对磁盘阵列或者固态硬盘这样的设备做优化用的，参
看这篇文章：
[http://lwn.net/Articles/395769/]
以及内核文档blkio-controller.txt中的描述：
CFQ sysfs tunable
=================
/sys/block/<disk>/queue/iosched/slice_idle
------------------------------------------
On a faster hardware CFQ can be slow, especially with sequential workload.
This happens because CFQ idles on a single queue and single queue might not
drive deeper request queue depths to keep the storage busy. In such scenarios
one can try setting slice_idle=0 and that would switch CFQ to IOPS
(IO operations per second) mode on NCQ supporting hardware.
That means CFQ will not idle between cfq queues of a cfq group and hence be
able to driver higher queue depth and achieve better throughput. That also
means that cfq provides fairness among groups in terms of IOPS and not in
terms of disk time.
/sys/block/<disk>/queue/iosched/group_idle
------------------------------------------
If one disables idling on individual cfq queues and cfq service trees by
setting slice_idle=0, group_idle kicks in. That means CFQ will still idle
on the group in an attempt to provide fairness among groups.
By default group_idle is same as slice_idle and does not do anything if
slice_idle is enabled.
One can experience an overall throughput drop if you have created multiple
groups and put applications in that group which are not driving enough
IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
on individual groups and throughput should improve.
What works
==========
- Currently only sync IO queues are support. All the buffered writes are
still system wide and not per group. Hence we will not see service
differentiation between buffered writes between groups.
在高速存储上，这样一组经验值可以获得较好的性能：
slice_idle = 0
quantum = 64
group_idle = 1
这些值在/sys/block/devicename/queue/iosched/中可以找到。
9 group_isolation
------------------
kernel document中有一个blkio-controller.txt文件，对这个参数做出了解释，
将其原文摘抄如下：
CFQ sysfs tunable
=================
/sys/block/<disk>/queue/iosched/group_isolation
If group_isolation=1, it provides stronger isolation between groups at the
expense of throughput. By default group_isolation is 1. In general that
means that if group_isolation=0, expect fairness for sequential workload
only. Set group_isolation=1 to see fairness for random IO workload also.
Generally CFQ will put random seeky workload in sync-noidle category. CFQ
will disable idling on these queues and it does a collective idling on group
of such queues. Generally these are slow moving queues and if there is a
sync-noidle service tree in each group, that group gets exclusive access to
disk for certain period. That means it will bring the throughput down if
group does not have enough IO to drive deeper queue depths and utilize disk
capacity to the fullest in the slice allocated to it. But the flip side is
that even a random reader should get better latencies and overall throughput
if there are lots of sequential readers/sync-idle workload running in the
system.
If group_isolation=0, then CFQ automatically moves all the random seeky queues
in the root group. That means there will be no service differentiation for
that kind of workload. This leads to better throughput as we do collective
idling on root sync-noidle tree.
我的理解，不一定准确：
cfq支持cgroup机制，可以区别对待属于不同cgroup的进程发下的io，给他们分
配不同的带宽。但这样会对效率造成比较大的影响。因为每个进程发送下来的读
写请求的位置可能差别很大，这样就会造成磁盘磁头来回的移动。所以，cfq提
供了这样一个参数，当group_isolation为0的时候，就把所有属于
SYNC_NOIDLE_WORKLOAD类型的cfq_queue都移动到root_group这个cgroup中。每
个进程都有几个它自己的cfq_queue，进程发送下来的IO，会根据IO的种类分别
放到不同的cfq_queue中去。从这个函数里我们可以看到怎么判断cfq_queue的种
类：
static enum wl_type_t cfqq_type(struct cfq_queue *cfqq)
{
if (!cfq_cfqq_sync(cfqq))
return ASYNC_WORKLOAD;
if (!cfq_cfqq_idle_window(cfqq))
return SYNC_NOIDLE_WORKLOAD;
return SYNC_WORKLOAD;
}
如果cfq_queue里面放的是同步的IO,那么它就是ASYNC_WORKLOAD类的，如果
cfq_queue里面放的不是idle类型的IO（优先级最低的一种IO，只在空闲时才处
理），那么它就是SYNC_NOIDLE_WORKLOAD类型的，否则（也就是idle类型的IO），它
就是SYNC_WORKLOAD类型的。
