说明 前面的文章我们详细阐述了Linux电梯调度算法的框架:某个请求如何进入电梯调度算法,在内部如何处理,如何被派发到底层设备。 之前,我们未就某一种具体的电梯调度算法作说明,本篇post就以特定的电梯调度算法—deadline调度为例,看看如何实现某种特定的电梯调度。 在前一篇post中我们了解到,实现某种特定的电梯调度算法其实就是实现特定的处理接口,接口形式由内核定义好,内核在处理请求时调用具体算法的相应接口即可,在前一篇post中我们也详细指出了内核在request处理的每个过程中具体调用了哪个接口。 所谓电梯调度算法,顾名思义,请求的处理按照块设备的偏移(一般是扇区号)朝一个方向移动,直到到达最远的对方,然后再按照反方向移动,就像电梯的运行过程一样。 而deadline电梯调度算法其实是在电梯调度算法基础上引入了饥饿消除机制:由于按照一个方向移动可能导致某些请求由于处在刺头移动的反方向上一直无法得到处理,于是需要为请求引入饥饿时间的概念,某些饥饿很久的请求会被优先处理。

Continue reading Linux deadline电梯调度算法

channel读写 对channel的读、写都可能会引起协程调度,这很自然,因为现在golang的channel操作均是同步操作。 向channel写数据 golang的channel分为无缓冲和有缓冲,前者主要用于同步,而后者主要用于消息传递。他们形式上的区别在于创建缓冲区时指定的缓冲区大小这个参数。 无论是无缓冲还是有缓冲channel,当向channel写数据发现被阻塞时,都需要将当前写的协程挂起,并进行一次调度。接下来让我们仔细分析下与channel中与调度相关的逻辑。

Continue reading golang调度时机研究

说明 前面有两篇文章我们聊了聊golang的协程调度算法。现在重新捡起来看看,真的是太皮毛了,羞愧,浅尝辄止的研究从来不是我的风格。 痛定思痛,从这里开始,我们深入深入再深入,直到将她扒光为止。 这篇文章可能会包含较多的个人思考,所以可能会有不少呓语,请忽略,如果你也能跟上我的节奏,那么你可能会很喜欢,否则,你可能觉得我是个神经病。

Continue reading golang 协程调度算法深究

说明 在前面的请求处理流程2中我们仔细介绍了块设备层的优化—蓄流和泄流。这里我们来介绍另外一个核心优化,电梯调度算法。 之所以出现电梯调度算法,还是出于IO效率太低考虑,对于传统的机械磁盘设备,最优的IO方法还是顺序大块读写,但应用层的读写方式千变万化,于是,块设备层就要操操心了,尽量将上层的随机读写给它排个序,做些简单合并,合并是为了每次发起的IO请求块更大,而排序则是尽量按照磁头移动的方向来进行读写,就像电梯一样,每次按照一个方向移动,直到其到达顶点,再按照反方向移动。 上面的道理就是电梯调度算法的核心,但是我们志不在此,而是要弄清楚Linux内核中电梯调度算法如何实现。 注意,为了跟上潮流,我们选择较新的内核实现,版本位3.10。

Continue reading Linux IO请求处理流程3-电梯调度算法

你见,或者不见我 我就在那里 不悲不喜 你念,或者不念我 情就在那里 不来不去 你爱或者不爱我 爱就在那里 不增不减 你跟,或者不跟我 我的手就在你的手里 不舍不弃 来我怀里 或者 让我住进你的心里 默然相爱 寂静喜欢

Continue reading 见与不见