安卓cpu调速器与IO调度基本知识，安卓I/O必看，不看会你后悔的！【高通吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：62,992贴子：
安卓cpu调速器与IO调度基本知识，安卓I/O必看，不看会你后悔的！收藏
本人一直不明白安卓I/O，今日有幸一见，分享给高通的gay
以下信息收集自网上。一、CPU调速器现在很内核都会增加新的CPU调速器，很多人不知道内核中的CPU调速器有什么用，下面转一个CPU调速器Governor说明:什么是Governor?→Android的CPU 的频率并不是一成不变的,会因应程式所需而调整频率,通常会视乎CPU Loading% 而升/降频,在特定时间再检查是否升/降。Governor就是默认的情景模式。【ondemand】按需模式:→按需调节cpu频率,不操作手机的时候控制在最低频率,滑屏或进入应用后会迅速提升至最高频率,当空闲时迅速降低频率,性能较稳定,但因频率变化幅度过大,省电方面只有一般的水平。是一种在电池和性能之间趋向平衡的默认模式,但是对于智能手机来说,ondemand在性能表现方面略有欠缺。【interactive】交互模式:→和ondemand相似,规则是“快升慢降”,注重响应速度、性能,当有高需求时迅速跳到高频率,当低需求时逐渐降低频率,相比ondemand费电【conservative】保守模式:→和ondemand相似,规则是“慢升快降”,注重省电,当有高需求时逐渐提高频率,当低需求迅速跳至低频率。【OndemandX】按需X模式:→在Ondemand基础上改进而来。关屏时手机进入睡眠状态时,锁定最高频率频率为500Mhz【Scary】胆小模式:→基于Ondemand修改,CPU提升速度比ondemand慢,同时具有smartass的特点【interactiveX】交互X模式:→在interactive基础上改进而来。关屏时手机进入睡眠状态时,锁定频率为最低值,同时在手机唤醒时能有更好的提升表现。比interactive更注重保护电池。【Wheatley】惠特利模式:→规则和Ondemand一样,但是响应速度稍慢,比Ondemand省电【hotplug】热拔插模式:→和ondemand模式差不多,当有高需求时直接跳到最高频率,当需求见效时逐级降低频率,但关屏时就单核低频运行,省电。【lionheart】狮心模式:→基于conservative模式,但性能有所提高,增快了CPU的调整速度【lulzactive】级别模式:→在interactive基础,根据负载逐级升高或降低频率,每一级频率有一个限制值,负载高于限制值就提高一级频率,低于限制值就降低一级频率。所以这个调速器在各个频率上的停留时间都很短。这个调速器的特点是在各个频率之间频繁变动,但是运行于最高和最低频的时间最多。【smartass】聪明模式:→是interactive和conservative的升级,根据资源使用智能提供一个适中的频率,空闲时自动降频,锁屏时自动固定频率。特色是锁屏后非常省电。缺点是部分机型锁屏一段时间后容易睡死。【smartassV2】聪明2模式:→smartass的升级版,平衡效能和耗电,升频快,降频慢,同时间亦会于锁屏时将频率降到最低,集成了休眠策略,不单单是指关了屏幕和开着屏幕的区别。【smoothass】活跃模式:→在smartass基础上改进得来的,性能更高,调节速度更快,耗电少【SavagedZen】平衡模式→在smartass的基础优化而来,同时注重电池和性能,使CPU达到一个更好的整体平衡【BrazilianWax】巴兹拉模式:→基本就和smoothass一样【Minmax】大小模式:→基于conservative的优化版,类似smartassV2,速度性能最好,比smartassV2略微耗掉【intellidemand】智能模式:→可根据GPU使用情况来针对性调节cpu频率,当GPU于重度使用时 ,所有动作都依照ondemand 不变。当3GP于闲置时,会自动限制cpu最高频率,将CPU最高频率锁死于1.0Ghz以减少耗电。关屏时亦会视乎 GPU 情况而作出调整。【Pegasusq】单控模式:→源自三星猎户座处理器的一个调速器,可以单独调控单个CPU内核,理论上性能不错也很省电。【badass】分工模式:一个新型的CPU调速器,只能用于多核CPU,可分开控制单个CPU内核,来分工完成不同的工作,并且跟着工作量的不同,分别调整单个CPU内核的频率,从而提高性能,节省资源。这个模式现在好像只能用在特定修改的rom中【performance】高性能模式:→高性能模式,按你设定范围的最高频率运行,即使系统负载非常低cpu的频率也为最高。性能很好,因为CPU本身不需要资源去调整频率,但是电量消耗较快,温度也高一些。【powersave】省电模式:→按设定最低频率运行,日常没有使用价值,除非配合setcpu情景模式,关屏睡眠时使用此调节模式,省电但系统响应速度慢。【userspace】用户模式:→任何情况下都会控制CPU运行在配置的频率范围内,配置中的用户自己添加的省电设置。在此情景模式下,降低CPU最大运行频率可以延长电池待机时间,但同时也会降低机器的唤醒速度,建议最好不使用该选项。【lagfree】无延迟模式:→很少用的调速器,不紧不慢型,无论负载变化快慢与否,CPU都按一定的停顿时间逐级升高或降低频率。【lazy】懒惰模式:→与 ondemand 相似,对于频率上升和下降的响应都很迟缓,可以忽略掉部分迅速变化的频率变化,优点是省电。二、CPU调速器优缺点详细介绍：Performance (Always Max)强制CPU一直运行在最高频率优点: 良好的性能、速度缺点: 大功耗，糟糕的电池续航时间，导致手机发热较严重，长期使用会对硬件造成一定的物理损坏Powersave (Always Min)强制CPU一直运行在最低频率优点:最小的功耗，最长的续航时间，最好的发热控制缺点:糟糕的性能，运行不流畅，有延迟、卡顿Userspace用户控制模式，这不是一个预制调速方案的调速器，它允许用户通过非操控内核的方法调节CPU，但是事实在出现"set cpu"这类软件之后就等于废物了优点:无缺点:无Ondemand按照实际需求快速进行频率调节优点:基本上实现了平衡，不错的性能兼有不错的续航缺点:不断地调整CPU频率消耗了一定的电力，导致这只能是一个“理想中”完美的调速器，频率升高时也偏敏感了一些(例如需要500，可能会给你升到650)Ondemand X基于Ondemand改进，区分开关屏状态情景优点：比Ondemand省电缺点：关屏状态下的频率被锁定在一个特定值 某些情况下可能睡死，稳定性不如OndemandConservative与Interactive相对，保守的调解方案，缓慢地提升频率，迅速地下降频率优点：比Ondemand稍省电，在真的需要之前不会提高频率缺点：缓慢地提升频率意味着在打开一些较大的APP或尝试唤醒待机中的机器会较慢Interactive与Conservative相对，快速提升频率，缓慢降低频率优点: 比Ondemand稍强的性能，较快的响应速度缺点: 在不需要时仍然维持较高的频率，比Ondemand耗电Interactive X基于Interactive改进，区分开关屏状态情景优点：比Interactive省电缺点：稳定性不如InteractiveSmartassInteractive与Ondemand合体，理想中的完美品优点: 比Ondemand更好的性能，比Interactive更好的续航缺点: 频率下降在不需要时仍然偏慢（虽然比Interactive好），关屏后盲目降频有时导致后台程序(比如同时挂着QQ,微信，微博)工作不正常Smoothass优化过的Smartass，快速调节频率平衡续航与性能优点：理论上比Smartass好的续航缺点：类似于Smartass，虽然真的比Smartass略好但频率下降在不需要时偏慢仍然存在SmartassV2重写的第二代Smartass，添加结合Conservative的一些特性优点: 在Smartass的基础上更好的性能与省电缺点: 关屏后的问题仍然没有解决LagFree开屏后一下子跳到一个中度偏高频率，然后类似Conservative地工作优点：算是解决了Conservative的迟钝问题缺点：电老虎，虽然比Performance省电...Lazy偏向Conservative的Ondemand，据说播放影音很好用优点：在频率提升/下降前都先调到一个特定的值，降低了关屏状态的最大值缺点：比Ondemand发热稍厉害，执行耗费较多资源的应用时如果进入了关屏状态过久可能会睡死Brazilianwax类似SmartassV2，比SmartassV2更积极提高频率优点：比SmartassV2好的性能缺点：比SmartassV2差的续航Intellidemand以Ondemand为基础，根据GPU状态区分情景优点：GPU忙时依照Ondmand模式工作，GPU"空转"或中度使用时频率锁定在定值缺点：执行不太依存GPU运算但较耗费CPU资源的应用时可能会性能不足，GPU“空转”(闲时)不够省电Lionheart基于Conservative降低了频率下降的敏感度优点：比Conservative强的性能缺点：进入高频率后几乎成了Performance模式Lionheart X 优化后的Lionherat优点：结合了一点Smartass的特定，降低功耗缺点：稳定性不如LionheartLuzactive更偏向Interactive的Smartass，分几个固定的档进行调控优点：分几个固定的档进行调控，性能功耗比较平衡缺点：分几个固定的档不够灵活，关屏会设定为最低处理器速度可能导致睡死Savagedzen基于SmartassV2编写，比Brazilianwax平衡优点：比SmartassV2好但比Brazilianwax差的性能，比SmartassV2差但比Brazilianwax好的续航缺点：稳定性不如BrazilianwaxScary基于Ondemand，提速比Ondemand慢优点：比Ondemand省电缺点：频率提升慢了有时候会叫人抓狂..Wheatley基于Ondemand，提速降速都比Ondemand慢优点：比Ondemand省电缺点：频率提升慢了有时引发卡顿，比Scary耗电Hotplug基于Ondemand，有性能需求直接最高，没性能需求直接最低优点：简单粗暴，还算平衡缺点：性能需求属于中度的情何以堪...Minmax 基于SmartassV2改进优点：比SmartassV2好的性能缺点：比SmartassV2耗电Badass只能用于多核CPU，分开控制单个CPU核心优点：节省资源，耗电和性能较平衡缺点：对内核要求苛刻，稳定系欠佳Pegasusq / Pegasusd源自Samsung Exynos ，单独调控单个CPU核心(资料不足)优点：理论上耗电性能较平衡缺点：不确定与其他芯片的兼容性，不确定三星芯片发热相对较大是否与此有关MSM-DCVS高通Krait核心芯片独有(资料不足)优点：据说可以用低功率获得高性能缺点：高通=睾痛 (undefined开玩笑的)三、I/O调度模式：（i/o即input/output的缩写，关于数据的读写操作，不同进程请求数据的优先顺序等等。io调度模式比较复杂，我没有具体测试，这里仅对ray上出现的几个模式做说明，部分参考xda、androidforums、wik1pedia、linuxarchive资料）noop这个调度模式会把并到一个简单的队列里。不适合有机械结构的存储器，因为没有优化顺序，会增加额外的寻道时间。属于最简单的一个调度模式，无视io操作优先级和复杂性，执行完一个再执行一个，如果读写操作繁多的话，就会造成效率降低。anticipatory其实这个有点类似于pc硬盘的NCQ功能，执行有预测性的调度，看起来似乎可以提高效率，不过因为它的预测机制会在进程将要结束一个读写操作时时开始准备下一个的预处理，所以会打乱系统正常的连续io调度，降低随机存取效率。用的人很少，不推荐。deadline顾名思义，用过期时间来排序io操作顺序，保证先出现的io请求有最短的延迟时间，相对于写操作，给读操作更优先的级别。是比较好的一个调度模式。cfq完全公平队列，是anticipatory模式的替代品，没有过多的做预测性调度，而是根据给定的进程io优先级，直接来分配操作的顺序。这个模式在linux上表现良好，但也许并不是最适合android的io调度模式，太强调均衡，而降低了连续读写数据的性能。vr具有和deadline相似的操作排序机制，有着最高的峰值读写速度，但是性能比较不稳定，也就是说可能跑出最高的分数，但是也会出现最低值。sio虽然基于deadline，但是它和noop一样，不会对io操作进行排序，所以有着noop那样快速的存取速度，但并没有过多优化io操作。如果不喜欢noop完全不参与调度，也可以选择这个。Row顾名思义ROW=Read over write（这个调度器的解释可以总结为：最大限制减少IO响应时间，并且重排执行操作，直接进行读写操作，给予IO最高优先值。在移动设备中，它将不会在桌面上有尽可能多的并行线程。通常它是一个单一的线程或最多2个同时工作的线程读写。有利于阅读的请求通过写入读取的延迟大大降低。比deadline好用，但是如果线程过多有可能会带来瞬间卡顿）
「天猫手机馆」-高通品牌旗舰店直销,新品现货,品类齐全,售后无忧,正品低价服务优!网购手机,来「天猫手机馆」让人放心的手机商城.&&惠&&聚各款热卖机型!分期付款无压力!
有舍有得，很难实现功耗与性能之间的真平衡。　　　　　　--贴吧助手一键签到，下载地址
多了好多CPUgovernorSmartass？Smart♂ASS，ASS♂WE♂CAN--A7战环蛇　 A15秒全家　A57轰成渣　
这标题，QQ空间即视感
顶——我咧个擦擦擦，随风而来，随风而去，乐享自在，不凡于心。
直接复制网上的，有点厉害
Conservative这个调度器大家最好别用，我用system monitor观察过，在这个调度器下CPU上升缓慢，但不用时频率根本降不下去，非常耗电
正要找这个来着
这么长，楼主直接说哪一个比较好
复制得好一手　-- 高端大气上档次，低调奢华有内涵。
有人发过了，而且是原创……　　　-- 第一次写小尾巴，好紧张啊！！！！！
看不懂啊　　　----来自国行大白兔LG G2
哪个好lz懂吗？
挽尊✎______________________________________ 　　　 　﹏₯㎕﹍这是个神奇的小尾巴　请不要试图去研究我是怎么发出来的 ฏ๎๎๎๎๎๎๎๎๎ฏฏด้้้้้็็　⣨
还是没有Taurusr
长　　 —　　　—　　　—　　　楼主你这么萌，我可以挼一下你的小咪咪么？
马克，为啥没有flops鱼头大，大鱼头，鱼头鱼头大鱼头
加入一个低功耗超灵敏的协处理器，用来管理cpu的电压和频率，快升慢降。可参考自动档汽车。
MSM-DCVS特好用
那个msm的调度器有用么，8960
太长不看了，看了也不懂　　　　　　　　 　-- 年轻真好呢
请问图中第一个？　——大快人心的大好事　
青铜星玩家
百度移动游戏玩家均可认证(限百度账号),
居然没有我大BFQ I/O？
我特妈看完了　　　----来自国行大白兔LG G2
登录百度帐号you have been blocked调整 Linux I/O 调度器优化系统性能
前言Linux I/O 调度器是Linux内核中的一个组成部分，用户可以通过调整这个调度器来优化系统性能。本文首先介绍Linux I/O
调度器的结构，然后介绍如何根据不同的存储器来设置Linux I/O 调度器从而达到优化系统性能。Linux I/O
系统简介Linux I/O调度器（Linux I/O Scheduler）是LinuxI/O体系的一个组件，它介于通用块层和块设备驱动程序之间。如图 1
所示。图1 Linux
I/O调度器介于通用块层和块设备驱动程序之间当Linux内核组件要读写一些数据时，并不是请求一发出，内核便立即执行该请求，而是将其推迟执行。当传输一个新数据块时，内核需要检查它能否通过。Linux
IO调度程序是介于通用块层和块设备驱动程序之间，所以它接收来自通用块层的请求，试图合并请求，并找到最合适的请求下发到块设备驱动程序中。之后块设备驱动程序会调用一个函数来响应这个请求。Linux整体I/O体系可以分为七层，它们分别是：1. VFS虚拟文件系统：内核要跟多种文件系统打交道，内核抽象了这VFS，专门用来适配各种文件系统，并对外提供统一操作接口。2.
磁盘缓存：磁盘缓存是一种将磁盘上的一些数据保留着RAM中的软件机制，这使得对这部分数据的访问可以得到更快的响应。磁盘缓存在Linux中有三种类型：Dentry
cache ，Page cache ， Buffer cache。3. 映射层：内核从块设备上读取数据，这样内核就必须确定数据在物理设备上的位置，这由映射层（Mapping Layer）来完成。4.
通用块层：由于绝大多数情况的I/O操作是跟块设备打交道，所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备，对上提供统一的Block
IO请求标准。5. I/O调度层：大多数的块设备都是磁盘设备，所以有必要根据这类设备的特点以及应用特点来设置一些不同的调度器。6. 块设备驱动：块设备驱动对外提供高级的设备操作接口。7. 物理硬盘：这层就是具体的物理设备。5种类型的Linux
I/O调度器Linux 从2.4内核开始支持I/O调度器,到目前为止有5种类型：Linux 2.4内核的 Linus Elevator、Linux 2.6内核的
Deadline、 Anticipatory、 CFQ、 Noop，其中Anticipatory从Linux
2.6.33版本后被删除了。目前主流的Linux发行版本使用Deadline、 CFQ、 Noop三种I/O调度器。下面依次简单介绍：1 Linus
Elevator在2.4
内核中它是第一种I/O调度器。它的主要作用是为每个设备维护一个查询请求，当内核收到一个新请求时，如果能合并就合并。如果不能合并，就会尝试排序。如果既不能合并，也没有合适的位置插入，就放到请求队列的最后。2
Anticipatory
Anticipatory的中文含义是"预料的，预想的"，顾名思义有个I/O发生的时候，如果又有进程请求I/O操作，则将产生一个默认的6毫秒猜测时间，猜测下一个进程请求I/O是要干什么的。这个I/O调度器对读操作优化服务时间，在提供一个I/O的时候进行短时间等待，使进程能够提交到另外的I/O。Anticipatory算法从Linux
2.6.33版本后被删除了，因为使用CFQ通过配置也能达到Anticipatory的效果。3 DeadLineDeadline翻译成中文是截止时间调度器，是对Linus
Elevator的一种改进，它避免有些请求太长时间不能被处理。另外可以区分对待读操作和写操作。DEADLINE额外分别为读I/O和写I/O提供了FIFO队列。Deadline的工作流程如图
2 所示。图2
Deadline的工作流程4 CFQCFQ全称Completely Fair Scheduler ，中文名称完全公平调度器，它是现在许多 Linux
发行版的默认调度器，CFQ是内核默认选择的I/O调度器。它将由进程提交的同步请求放到多个进程队列中，然后为每个队列分配时间片以访问磁盘。对于通用的服务器是最好的选择,CFQ均匀地分布对I/O带宽的访问。CFQ为每个进程和线程,单独创建一个队列来管理该进程所产生的请求,以此来保证每个进程都能被很好的分配到I/O带宽，I/O调度器每次执行一个进程的4次请求。该算法的特点是按照I/O请求的地址进行排序，而不是按照先来后到的顺序来进行响应。简单来说就是给所有同步进程分配时间片，然后才排队访问磁盘，CFQ的工作流程如图
3 所示 。图3 CFQ的工作流程5 NOOPNOOP全称No
Operation,中文名称电梯式调度器，该算法实现了最简单的FIFO队列，所有I/O请求大致按照先来后到的顺序进行操作。NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织。它是基于先入先出（FIFO）队列概念的
Linux 内核里最简单的I/O 调度器。此调度程序最适合于固态硬盘。NOOP的工作流程如图4 所示。图4
NOOP的工作流程I/O调度器的选择目前主流Linux发行版本使用三种I/O调度器：DeadLine、CFQ、NOOP，通常来说Deadline适用于大多数环境,特别是写入较多的文件服务器，从原理上看，DeadLine是一种以提高机械硬盘吞吐量为思考出发点的调度算法，尽量保证在有I/O请求达到最终期限的时候进行调度，非常适合业务比较单一并且I/O压力比较重的业务，比如Web服务器，数据库应用等。CFQ
为所有进程分配等量的带宽,适用于有大量进程的多用户系统，CFQ是一种比较通用的调度算法，它是一种以进程为出发点考虑的调度算法，保证大家尽量公平,为所有进程分配等量的带宽,适合于桌面多任务及多媒体应用。NOOP
对于闪存设备和嵌入式系统是最好的选择。对于固态硬盘来说使用NOOP是最好的，DeadLine次之，而CFQ效率最低。查看Linux系统的
I/O调度器查看Linux系统的I/O调度器一般分成两个部分，一个是查看Linux系统整体使用的I/O调度器，另一个是查看某磁盘使用的I/O调度器。查看当前系统支持的I/O调度器，使用如下命令：清单 1.
查看当前系统支持的I/O调度器# dmesg | grep -i scheduler
1.508820] io scheduler noop registered
1.508827] io scheduler deadline registered
1.508850] io scheduler cfq registered (default)清单1的代码显示cfq是目前的I/O调度器。查看某块硬盘的IO调度算法I/O调度器，使用如下命令：清单2.
查看一个硬盘使用的I/O调度器# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]清单2显示当前使用的调度器是cfq，就是括号括起来的那一个。修改Linux系统的
I/O调度器修改Linux系统的 I/O调度器有三种方法，分别是使用shell命令、使用grubby命令或者修改grub配置文件。下面依次介绍：使用shell命令Linux下更改的I/O调度器很简单。不需要更新内核，可以使用shell命令修改：清单3.
查使用shell命令#echo noop & /sys/block/sdb/queue/scheduler清单3的命令把noop设置为一个磁盘的I/O调度器，你可以随时更改而无需重启计算机。永久修改默认的I/O调度器使用shell命令修改I/O调度器，只是临时修改，系统重启后，修改的调度器就会失效，要想修改默认的调度器，有两种方法使用grubby命令或者直接编辑grub配置文件。使用grubby命令例如需要把I/O调度器从cfq调整成 DeadLine ，命令如下：清单4.使用grubby命令# grubby --grub --update-kernel=ALL --args="elevator=deadline"清单4的命令，通过设置内核加载参数, 这样当机器重启的时候，系统自动把所有设备的 I/O调度器变成 DeadLine 。使用编辑器修改配置文件也可以直接编辑grub的配置文件 ，通过修改grub配置文件，系统自动把所有设备的 I/O调度器变成cfq。操作过程如下：清单5
使用vi编辑器修改grub配置文件#vi cat /etc/default/grub
#修改第五行，在行尾添加#
elevator= cfq
然后保存文件，重新编译配置文件，
#grub2-mkconfig -o /boot/grub2/grub.cfg重新启动计算机系统即可。总结Linux I/O调度器是 Linux 内核中的一个组成部分，用户可以通过根据不同的存储器来设置 Linux I/O 调度器从而达到优化系统性能。
一般来说 NOOP 调度器最适合于固态硬盘，DeadLine 调度器适用于写入较多的文件服务器，比如Web服务器，数据库应用等，而CFQ
调度器适合于桌面多任务及媒体应用。参考资料
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=LinuxArticleID=1048962ArticleTitle=调整 Linux I/O 调度器优化系统性能publish-date=下次自动登录
现在的位置:
& 综合 & 正文
IO调度器原理介绍
【上篇】【下篇】IO调度策略之我见
<a data-traceid="question_detail_above_text_l&&
IO调度策略对上面的块设备层和下面的磁盘驱动起作用，它实质上切断了数据从应用程序到磁盘的路径，从而也就解除了块设备和底层驱动程序之间的耦合，这样的话就可以匹配上下两层之间的不和谐，试想如果磁盘速度很慢，那么就可以在IO调度策略中加入可以避免过多寻道的操作，比如AS预测调度器，比如合并不同的请求，但是对于Flash-DOM之类的可以随机存储的存储器就没有必要采用复杂的调度算法了。对于linux的实现，IO调度模块对上层实际上就是一个入队操作，根据系统管理员的配置或者自适应决断结果将一系列IO请求分配到一系列队列中，入队的策略主要在于怎么排队，比如一共有哪些队列，一个请求应该排入哪个队列，之后的事情就不用管了，而出队操作是IO调度模块下层的接口，它主要负责从哪个队列选择下一个要服务的请求，它不管块设备层是怎么将请求排入队列的，然而到此为止了吗？为了使得一些策略起作用，同时也为了使得“跨层操作”最小化，所谓的队列中必须积攒了一定数量的IO请求的时候才能激发调度，也就是说块设备层不断的将请求加入到策略化的队列中，而驱动程序并不是马上就对队列中的请求进行服务，而是等到队列中的请求积攒到一定数量的时候再开始服务过程。我们知道，计算机中，凡是跨层操作，开销几乎一定大于层内操作，这是因为分层是为了解耦合，是为了机制和策略分离，层与层之间抽象出了接口，而接口需要确保极大的兼容性，所以为了照顾接口的兼容性和其本身的安全性稳定性以及正交性，也就必然需要将问题一般化，因此就需要一个环境的切换，因此性能的牺牲也是必然的，我们常常听说尽量少进行系统调用也就是这个道理，对应到IO调度层也是这个道理，因此我们千万不要要求磁盘驱动程序不断的取得请求不断的服务，让它休息一会也许会取得更好的性能。linux的实现中，用了一个十分形象的方式实现了这个，plug和unplug，这两个词汇从其本意上就能让人理解linux的实现方式，plug是活塞，unplug是拔下活塞的意思，起初，在队列的开头赛上一个活塞(plug)，待到队列中的请求达到一定数量后者塞上活塞已经有一段时间以后，那么拔下活塞(unplug，每个磁盘的请求队列都有一个unplug回调函数)，这么解释就什么都清楚了。
IO调度有很多策略，起初就是linus电梯，这个算法很直观同时也必然很简单，2.6内核之后，添进来很多算法，我总结了一下基本就是两点，其中cfq是按照网络负载均衡算法改造的，而其他的算法都是对linus电梯的改进，deadline算法避免了饥饿，避免了磁盘中临近的区域大量的请求被瞬间提交，从而造成早期提交的一个稍微远一些的请求饥饿，因为deadline算法中每一个请求都有一个饥饿时间限制值，一个请求同时要插入到两个队列，其中一个队列是linus电梯里面的队列，另一个是FIFO的按照到达时间排序的队列，这个FIFO队列也按照read和write进行了区分，read队列的饥饿时间限制要更短一些，因为应用程序对于读请求一般都是同步意义的，并且对于磁盘文件来讲如果顺序读的话，前面的读没有完成后面的读更是无法进行，而写操作就不是这样的，应用程序写文件一般都是异步意义上的，更复杂的，如果很多进程都在写一个文件的一个区域，那么只要最后一个写操作完成就可以了，前面的几个都可以直接抛弃，再者，写入缓存还是写入磁盘，这都不是应用程序所关心的，因此写操作的超时时间要大于读操作，deadline在linus电梯的基础上避免了饥饿，那么引入了另一个问题，试想如果一系列写操作正在进行，这些写操作都是经过linus电梯算法合并和排序过的，这时突然有个读请求饥饿超时到时间了，那么不可避免的，磁头要移动到读请求的位置，这样显然降低了磁盘的吞吐量，然而这个突然的移动还不得不做，读请求完成以后，按照deadline的逻辑，磁盘的磁头又返回刚才被读请求打断的写请求的位置，然后...，这一次又一次的移动，不断降低着磁盘的吞吐量，并且磁头频繁移动，损坏磁盘，AS算法出现了，在不得不服务超时读请求后，不是返回写请求，而是等待一段时间，因为调度策略认为，在等待的这一段时间内，可能会有另一个读请求，将读请求积攒在一起总比来来去去要好，AS调度策略的要点在于到底是否要等待以及等待多久，这些都是按照对进程的统计完成的，算法很复杂，然而思想却很简单，一个不得不做的读请求完成以后，IO调度器在一段时间内等待“相邻”读请求的到来，随着预测得到的等待时间的增长，“相邻”的概念范围越来越宽，并且也能加进来一些写请求，最终如果这个相邻的概念已经扩展到了整个磁盘，那么AS算法也就退化成了deadline算法。实质上，AS算法就是摆脱了deadline算法的弊端，它的弊端就是磁头可能来回移动从而降低了吞吐量，而deadline算法是摆脱了linus电梯的弊端，它的弊端就是会引起饥饿，总而言之，吞吐量和磁头寻道紧密相连，它和饥饿是一对冤家，需要权衡！
原文链接：}