2016年2月9日星期二

SH_DIV

#define SH_DIV(NOM,DEN,LSH) (   (((NOM) / (DEN)) << (LSH))              \
                             + ((((NOM) % (DEN)) << (LSH)) + (DEN) / 2) / (DEN))


NOM = NOM / DEN + NOM % DEN
 

(NOM << LSH) / DEN

= (NOM / DEN + NOM % DEN) << LSH / DEN

= (NOM / DEN) << LSH

一个描述paxos算法的恰当的例子

最近看了paxos算法。从发明者本人开始,到网上各种介绍算法的文章,都是在通过各种例子说明这个算法。但我觉得,似乎大部分的例子在让人理解的时候都会引入歧义。比如发明者本人以一个虚构的希腊城邦为例,我看了例子后很长时间都没有搞明白一点:当提案通过之后,是不是还能够继续修订提案?比如这次会议决定了拦路抢劫判10年,通过之后是不是可以再重新提案修改为判20年?当我最终弄明白这个算法之后,自己想了下面一个例子。我认为,我这个例子可以避免误解,让人直接明白paxos算法究竟要解决的是什么问题。

假设这样的一个场景:你和另外四个人被一个性格古怪的恐怖分子劫持了,他要求和你们五个人做一个游戏。游戏规则是,他会把你们五个人分别放进五个房间,每个房间都有一张桌子和一个窗户。你们互相之间都看不到其他人的房间或窗户。桌子上放着三样东西,这三样东西各不相同,但每人桌子上的东西是相同的。比如,你的桌子上是铅笔,橡皮,绳子,其他人的桌子上也都是铅笔,橡皮,绳子。但摆放的位置可能不同。你们每人需要从桌子上选择一件东西扔到窗户外面。如果有三个或更多的人将同样的东西扔到了窗户外面,就算你们赢了,你们每人会得到1千万元的奖励,如果没有三个人扔出同样的东西,比如两个人扔了橡皮,两个人仍了铅笔,一个人扔了绳子,那么你们就输了。输了就全都被枪毙。在游戏分出输赢之前,你们五个人会被一直关在屋子里,不许出来,你们有吃有喝,不会饿死。

接下来是关键的条件:你们每人都可以拿着一部手机,用来互相通信。这个手机的功能被做了如下限制:不能打电话,只能发短信,且每个人只能发送短信给其他四个人。手机通讯录上记录了其他四个人的联系方式。但这个手机短信的收发功能不大可靠,你发送的一条短信,可能丢失,最终没有人收到,也可能延迟很久才被人收到。而且,还有一点不利的条件,你们中最多可能有两个人完全无法和别人联络,也就是说,可能有0到2个人,发出去的短信别人永远无法接到,也永远受不到别人的短信。

前提条件已经讲完了,实际上问题就是,你们五个人进入屋子后,要通过手机短信协商出把哪件东西扔出窗外,并且这个手机短信的传输信道很不靠谱,可能会丢失短信,或者让短信延迟很长时间才会收到。甚至,可能会有1到2部手机从一开始或者从某个时间点开始,永远都联系不上其他三部手机。现在,在分别被关进屋子之前,你们五个人被聚集在一起,可以一起商量一个办法,商量进入屋子后,如何才能让至少三个人把同一件东西扔出窗外。

我尝试分别问了两个人,这两个人的第一反应是相似的,都提出了这样的办法:选定一个人,由这个人发短信给其他人,告诉其他人该扔哪件东西。我反驳说:按照前面提到的条件,最多可能有两个人可其他人完全无法通讯,如果恰好是开始选出的人,岂不是永远都无法做出决定了?这两个人接下来的反应也大同小异:那就给五个人编号,分别为1,2,3,4,5,如果1发出去的消息别人收不到,那就由2发,如果2发出去的别人还收不到,那就由3发。我会反问:由于消息可能会延迟也可能会丢失,假设1和2的消息都延误了很久,3开始发消息了,结果最终只有5收到了1的消息,1发给其他人的消息都丢失了,4收到了3的消息,3发给其他人的消息也都丢失了。而2没有收到任何人的消息,2发出去的消息也都丢失了。这时1,5扔出去了一样的东西,3,4扔出去了一样的东西,2自己扔出去了一件东西,结果没有3个人扔一样的东西,你们就输了。所以,这样的思路是行不通的。

Paxos算法是一个可行的思路。按照paxos算法,我们可以为每个人都定下这样的规则:

进入屋子之后,随机等待一段时间,开始和别人联系,联系的内容就是提议将某件物品扔出窗外。提议分两步进行,第一步是发送短信联系5个人中的任意3个人(可以包括自己),短信包含如下内容:
我是xxx,我想进行提议,本次提议的序列号SN
我们把这条短信叫做“短信1”
注意,这条短信中不包括提议仍哪件东西的具体内容,只表明你想进行提议,SN是一个全局唯一的序列号,并且单调递增。这里我们可以先假设SN就是时间戳,每个人打算提议时就记下当前的时间,把时间戳发出去。当然,题目中并没有说关在屋子里的人可以看时间,而且在两个人同时进行提议的时候,时间戳也可能相同,不能保证全局唯一性。在讲完paxos算法后,我会说明如何在不借助任何外部工具的情况下构建出这样一个全局唯一并且单调递增的SN号。但目前,为了简单起见,我们先假设SN号就是时间戳。

大家都是随机等待一段时间开始发“短信1”的,随机的目的是为了让大家把发短信的时间岔开。但有可能两个人在很接近的时间内发送了“短信1”给同一个人,这样有人就接连收到了两条“短信1”,我们给接收到短信的人指定这样一个规则:他如果同时收到了多条“短信1”,就比较SN号,只回复SN号最大的那个人发来的短信,其他SN号比较小的,就都不理会。

对于回复“短信1”的人,如果他之前还没同意过任何提议,则回复内容如下:
我是xxx,我收到序列号为SN的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
如果回复“短信1”的人之前同意过其他人的提议(我们稍候会介绍如何同意其他人的提议),那么他选出所有他同意的提议里面,SN号最大的那个提议,并回复内容如下:
我是xxx,我收到序列号为SN的提议请求,我同意你进行提议,并且,我之前同意过的最新的提议为"扔出xx",该提议的序列号为SN1。

对于发送“短信1”的人,他等待一段固定的时间,比如说十分钟,如果在十分中内没有收到3个人对“短信1”的回复,比如只收到了2个人的回复,或者也可能一个回复都没有收到,那么他就再随机等待一段时间,然后再尝试找3个人发“短信1”,每次找的3个人最好都有变化,别总是找固定的3个人,因为如一开始的假设,可能有最多两个人和其他人是完全失联的,如果总找完全失联的人,就可能永远集不齐3个回复。

当某个人在某次发了“短信1”之后,如果收到了3个人对“短信1”的回复,那么他开始发送“短信2”。“短信2”的内容视他收到的对“短信1”的回复而定。假如他收到的3个对“短信1”的回复都说“我之前没有同意过任何提议”,那么,他就任选一个桌子上的物品,比如说橡皮,然后发送“短信2”的内容如下:
我提议把橡皮扔出窗外,我的序列号是SN。
这个SN依然是发送短信1时使用的序列号,不是新生成一个序列号。

如果他收到的三个对短信1的回复中有一个或多个人回复说“我之前同意过的最新的提议为"扔出xx",该提议的序列号为SN1”,那么他就从这些回复中选出序列号最大的那个提议,看看那个提议是建议扔出什么东西,然后他也提议仍同样的东西。比如,他看到3条对“短信1”的回复里面,序列号最大的提议是扔出铅笔,那么他就发送“短信2”的内容如下:
我提议把铅笔扔出窗外,我的序列号是SN。
注意,扔出铅笔是对“短信1”的回复里面序列号最大的那个提议的内容,但序列号SN依然是他自己发出“短信1”时确定的序列号。

他把“短信2”发送给任意3个人,可以和之前发给“短信1”的三个人相同,也可以不相同。然后他等待其他人的回复,如果他收到了3条回复,并且内容如下:
同意你的序列号为SN的提议
那么他就把他提议的东西扔出窗外。如果等了一段固定的时间,没有集齐3个回复,那么他就再随机等待一段时间,然后重新从“短信1”开始发送。

接下来我们说收到“短信2”的人如何回应。如果一个人收到了“短信2”,他首先看看有没有收到序列号更大的"短信1"或者“短信2”,如果有的话,就回复序列号最大的那条“短信1”或者“短信2”,忽略这条最新收到的“短信2”。注意,由于发送信息可能会有延迟,最新收到的短信的序列号不一定是最大的,因此,他可能会忽略最新收到的短信。如果这个人发现他收到的这条“短信2”是他所有收到的短信里面序列号最大的(或者并列最大的),那么他就回复说:
同意你的序列号为SN的的提议
关于并列最大的序列号,我们说序列号全局唯一,并且单调递增,但同一个序列号即要被用于”短信1“也要被用于”短信2“,可能这个人收到过序列号为SN1的“短信1”,然后他又收到了序列号为SN1的“短信2”,因此,可能出现并列最大的序列号。

当收到“短信2”的人做出了这样的回复之后,他就记录下这是他最新同意的提议,如果接下来他又收到序列号更新的“短信1”的时候,他就回复说他同意了这个提议。当他回复了“短信2”之后,他可能又收到一个序列号为SN1的“短信2”,这个SN1比SN更大,这时,他也会做如下回复:
同意你的序列号为SN1的的提议
同时,他也会记录下,SN1以及其对应的提议是他同意过的最新的提议,再收到“短信1”的时候,他会把SN1以及SN1对应的提议返回给发送“短信1”的人。

每个人都按照上述规则发送“短信1”和“短信2”,并且处理别人发来的“短信1”和“短信2”。最终,这5个人会达成一致,把同一件东西扔出窗外,或者,假设有1或2个人处于完全失联的状态的话,其余的人会达成一致,把同一件东西扔出窗外。

算法的正确性有严格的证明,可以在网上搜到。我写这篇文章的目的是方便大家理解paxos算法,对于算法的正确性,我就不作证明了。下面我们通过具体的例子来感受一下算法的运行:

按照本文开头假设的场景,有A,B,C,D,E五个人,他们被分别关进了5个屋子,每个屋子里面的桌子上,都摆放着铅笔,橡皮,绳子。现在,他们要通过可能会丢包/延迟的手机短信,对把哪个东西扔出窗外这个问题达成一致。

进入屋子之后,过了一段时间,A决定发送“短信1”了,A编辑如下短信内容:
我是A,我想进行提议,本次提议的时间戳是02:15
如前所述,我们暂时用时间戳代替序列号,并假设不会有两个人使用相同的时间戳。
A决定把“短信1”发给A,B,C三个人。A发给自己就不用真的发送了,他马上就知道了自己发送的内容。然后A,B,C三个人按照前面所述的规则对“短信1”做出回应。A刚刚发出“短信1”,E也决定发送“短信1”,E编辑如下短信内容:
我是E,我想进行提议,本次提议的时间戳是02:20
然后,E决定把他的"短信1"发送给C,D,E三个人。我们假设这些短信都在短时间内被接收到了。于是A,B,C收到了A的“短信1”,C,D,E收到了E的“短信1”,A和B马上给A做出回应:
我收到时间戳为02:15的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
D和E也马上对E做出回应:
我收到时间戳为02:20的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
C会收到A和E两个人的短信1,C具体怎么做,取决于收到短信的顺序。
情况1:C先收到了E的“短信1”或者C正在回复A的短信1但还没发送的时候收到了E的“短信1”,C都会决定不再理会A,只对E回复:
我收到时间戳为02:20的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
在这种情况下,E会收到C,D,E三个人对“短信1”的回复,并开始发送“短信2”,而A不会收到3分对“短信1”的回复,于是等待一段时间后,A会发送一个时间戳更新的“短信1”。A可能只等待了一分钟,就迫不及待的发送了一个时间戳为02:16的“短信1”,如果C收到了的话,依然是不与理会,直到A发送的“短信1”的时间戳大于02:20,C才会理会A。

情况2:C先收到了A的“短信1”,并且,直到C回复A之前,都没有收到E的短信,C会回复A:
我收到时间戳为02:15的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
然后,等C收到了E的“短信1”,C也会回复E:
我收到时间戳为02:20的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
虽然C对A和E都进行了回复,但C回复的最新的时间戳是02:20,因此当C再收到A发来的时间戳为02:15的“短信2”的时候,C不会理会A的“短信2”。由于D和E回复了E的“短信1”,他们会记住他们接收的最新的时间戳是02:20,因此D和E收到A的时间戳为02:15的“短信2”时,也不会理会。C,D,E都不会理会A的“短信2”,所以A不可能收齐三个人对“短信2”的回复,因此,A的时间戳为02:15的提议,是不会得到通过的,A最终会由于很长时间都没有收齐3个对“短信2”的回复,而使用新的时间戳重新发送“短信1”

我们看,无论是情况1还是情况2,A的时间戳为02:15的提议都不会得到通过。而假如一切顺利的话,E收到3个对“短信1”的回复后,编辑“短信2”如下:
我提议把铅笔扔出窗外,我的时间戳是02:20。
然后,E决定把“短信2”发送给A,B,C。A和B在接收到E的“短信2”之前,接收到的最新的时间戳是A发出来的02:15,因此,A和B会发现他们收到的这条来自E的“短信2”的时间戳比他们以前收到的都新,按照前面约定好的规则,A和B会回复E:
同意你的时间戳为02:20的提议
并且,A和B都会记下:我最新同意的是时间戳为02:20的提议,提议的内容是仍铅笔。
对于C来说,他收到最大时间戳是02:20的“短信1”,这次他又收到了时间戳为02:20的“短信2”,按照前面规定的规则,出现并列最大的序列号时,需要对短信2做出回应,于是C回复E:
同意你的时间戳为02:20的提议
并且C会纪录下:我最新同意的是时间戳为02:20的提议,提议的内容是仍铅笔。

当A,B,C都决定同意E发出来的“短信2”之后,仍铅笔这个决定就已经被确定下来了。尽管A,B,C,D,E五个人还没有一个人知道这件事,但仍铅笔这件事已经确定了。比如,在A,B,C都回复C的“短信2”之后,B的回复由于通讯链路故障丢失了,E没有受到B的回复。这样,E就只收到了2个对“短信2”的回复。E会过一段时间重新发送“短信1”。

我们假设E在收到了两个A和C的两个“短信2”之后,还在等待B的回复。这时,C又发起了新一轮的提议,C编辑“短信1”如下:
我是C,我想进行提议,本次提议的时间戳是02:30
C决定把"短信1"发送给A,D,E,
按照规则,A会回复C:
我收到时间戳为02:30的提议请求,我同意你进行提议,并且,我之前同意过的最新的提议为"扔出铅笔",该提议的时间戳为02:20。
D和E都会回复E:
我收到时间戳为02:30的提议请求,我同意你进行提议,并且,我之前没有同意过任何提议。
C收到了A,D,E对“短信1”的回复之后,发现回复中提到的最新的提议是扔出铅笔,于是,C编辑“短信2”如下:
我提议把铅笔扔出窗外,我的时间戳是02:30。
C把“短信2”发送给任意3个人,比如A,B,D,假设运气好的话,他会收到3个这样的回复:
同意你的时间戳为02:30的提议
C自己知道他同意过的02:30的提议是扔出铅笔,于是C安心的把铅笔扔出窗外。为了加快达成一致的速度,C可以更新记录下:
我最新同意的是时间戳为02:30的提议,提议的内容是仍铅笔。
C也可以不更新上面这条记录,依然保持自己的记录为:
我最新同意的是时间戳为02:20的提议,提议的内容是仍铅笔。
回顾一下前面的流程,02:20这个记录内容是C回复E的短信2时记录下的。

C扔出去铅笔之后,就不再发送“短信1”或是“短信2”了,但会按照规则并依据自己收到的时间戳回复别人的“短信1”和“短信2”。最终,除去永远失联的0到2个人之外,其他人都会把铅笔扔出窗外。

接下来我们简单说说序列号的问题,paxos要求每个节点都能够生成全局唯一并且单调递增的序列号,当我一开始看paxos算法的时候,就在思考这个序列号如何生成。首先我想到的是时间戳,但两个不同节点上的时间戳可能是相同的,解决办法是给每个节点分配一个唯一的编号,比如上面的例子中,A,B,C,D,E五个人的编号分别为0,1,2,3,4,每个人想进行提案的时候,都获取一个时间戳,把这个时间戳转换为epoch(从1970年1月1日到现在的毫秒数),用这个epoch作为序列号的最高位,把自己的编号作为序列号的最低位。这样由于时间戳始终在不停的增长,序列号一定是单调递增的,当两个人在同一时间获取序列号时,由于每个人的编号不同,最低位不会相同,因此可以两个人的序列号不会一样。注意,我们要让epoch作为高位,每个人的编号作为低位,反过来是不行的。假如用每个人的编号作为高位,而epoch作为低位的话,一个人的序列号就永远无法超过另一个人的序列号了,而每个节点只要收到了一个大的序列号,就不会再处理小序列号的请求了,因此这会造成算法永远无法收敛。
进一步的,我们还可以得到一个更紧凑的序列号,假设一共有n个节点(在我们的例子中,n=5),每个节点的编号为i,i是从0到n-1的整数,epoch为时间戳。那么可以用如下公式得到序列号:
sn = epoch * n + i
比如n等于5的时候,如果按照一开始提出的序列号方案,sn号的低位只能用到了0,1,2,3,4,sn号永远不可能为5,6,7,8,9,这对于sn号的取值空间来说也是一种浪费,后面提出的这个公式可以让sn号的取值空间没有浪费。想到这里,我觉得我已经解决序列号的问题了,于是不再考虑生成序列号的问题。直到我无意中发现,google在Chubby的论文中提出了一个更简洁的方案:
系统中的每个节点都维护一个计数器,从0开始计数,每当这个节点打算新提出一个提议的时候,就把这个计数器加1,系统的总节点个数是n,每个节点都有一个唯一编号,从0到n-1,假设当前计数器的值为m,那么序列号为:
sn = m * n + i
对比我自己想的那个公式,把epoch换成了m,不需要用真实的时间了,只要每个节点维护一个单调递增的计数器就行。至此,序列号的问题算是完美的解决了。

说句题外话,raft算法所用的虚拟时钟相对于paxos lease算法的真实timer,看起来和chubby论文对我设想的序列号公式的简化非常神似。
基本的paxos算法 + paxos lease + multi paxos可以实现一个分布式的状态机系统。近些年提出来的raft算法号称可以实现paxos同样的功能,但更好理解。在我看来,raft本质和paxos是相通的,我倾向于认为raft就是进化到极致的paxos。

2014年11月13日星期四

pcaptraceroute,一个用来检测GFW的工具

从目前的经验来看,GFW对于IP在黑名单中的网站也并不是全部数据包都拦截,似乎是为了隐藏自己的存在,GFW只选择性的拦截返回包,而不拦截第一次发送出来的包。

现象1:你在境内的一台电脑上发送一个TCP syn包给境外一个被GFW拦截的服务器,在境外的服务器上用tcpdump抓包,会发现这个境内的电脑发送的syn包可以成功到达,同时,tcpdump也会显示,境外的服务器按照网络协议的要求返回了一个ack包给境内的电脑,但境内的电脑无法接受到这个返回的ack包。

现象2:从境外被GFW屏蔽的服务器上发送一个TCP syn包给境内的电脑,境内的电脑可以接受到这个syn包,但境内的电脑返回的ack包无法达到境外的服务器。

GFW这种方式让人很难检测出它的存在,因为你主动发过去的包是可以通过的,它只把返回的包拦截下来,这样在你看来是畅通的,但对方没有返回。因此,我写了一个pcaptraceroute程序,它用和traceroute同样的原理来检测网络中间节点的可达性,只不过,它发送的是TCP的ack包。这样,如果在一台被GFW屏蔽的主机上运行这个程序,就可以检测出数据包是从哪一跳开始完全不可达了。

项目主页:

2012年8月13日星期一

部分cfs调度器的tuning参数

最近看了rhel6.2内核的cfs进程调度代码,作为学习总结,把相关的部分tuning参数做了下整理,摘录如下。

* sched_child_runs_first
  当创建子进程时,保证子进程会在父进程之前运行。在创建子进程时,首先会
  将子进程的虚拟运行时间设置为min_vruntime,这个min_vruntime大约等于当
  前运行队列中所有进程的虚拟运行时间的最小值,然后,看sched_features中
  是否设置了START_DEBIT位,如果这一位被设置了,表示要给新创建的进程的
  虚拟运行时间再增加一些,这样会让它的运行时间向后延迟,以防进程通过不
  停的fork来不停的获得cpu时间。当设置完子进程的虚拟运行时间之后,会判
  断sched_child_runs_first是不是设置为1,如果是的话就比较父进程和子进
  程的虚拟运行时间,如果父进程的虚拟运行时间比较小的话,就交换父子进程
  的虚拟运行时间,这样子进程就会在父进程之前运行了。

* sched_min_granularity_ns
  这个值在两个地方会用到。一个是计算nice值为0的进程运行一次需要的时间。
  如果进程的总数大于sched_latency/sched_min_granularity个,就用
  sched_min_granularity_ns的值乘以进程的个数,将乘积作为nice值为0的进程
  调度一次运行的时间。然后每个进程会以此为基准,按照自己的优先级来计算
  自己被调度一次的运行时间。。另一个用途是判断当前进程是否要被调度下
  CPU的时候。如果当前进程的执行时间已经超过了它被调度一次所允许的执行时
  间(其实也可以说是时间片,尽管cfs声称自己没有时间片),那么必然要被调
  度下CPU。但如果它的时间片还没到期,在判断它的运行时间是不是比
  sched_min_granularity_ns小。如果是的话,那么就肯定不把它调度下CPU,如
  果进程的运行时间比sched_min_granularity_ns大的话,就用当前进程的虚拟
  运行时间减去runqueue上虚拟运行时间最小的进程的虚拟运行时间,如果差值
  比当前进程的时间片(这个时间片确实不是传统的时间片,总是随当前负载的
  状况变化)还大的话,那么当前进程也会被调度下CPU。

* sched_latency_ns
  计算nice值为0的进程运行一次所需的时间时用到。。如果进程总数小于等于
  sched_latency/sched_min_granularity个,就将sched_latency_ns作为nice
  值为0的进程运行一次的时间,否则按照前面介绍sched_min_granularity_ns
  时的方法计算。

* sched_wakeup_granularity_ns
  判断一个进程是否可以抢占当前进程时用到。如果该进程的虚拟运行时间比当
  前进程的虚拟运行时间大,那么肯定不能抢占。如果该进程的虚拟运行时间比
  当前进程的虚拟运行时间小的话,就计算出两者之差vdiff。如果vdiff大于一
  定的范围的话,就可以抢占,否则不可以抢占。
  sched_wakeup_granularity_ns就是用来确定这个范围的。它表示一个nice值
  为0的进程要抢占当前进程,它的虚拟运行时间需要被当前进程的虚拟运行时
  间小多少,其他优先级的进程以此为基准进行调整,优先级越高的进程,需要
  的差值越小。

* sched_tunable_scaling
  当内核试图调整sched_min_granularity,sched_latency和
  sched_wakeup_granularity这三个值的时候所使用的更新方法,0为不调整,1
  为按照cpu个数以2为底的对数值进行调整,2为按照cpu的个数进行线性比例的
  调整。

* sched_features
  每个bit都表示调度器的一个特性是否打开。在sched_features.h文件中记录
  了全部的特性。

* sched_migration_cost
  用来判断一个进程是不是cache hot的。如果进程的运行时间小于
  sched_migration_cost就认为是cache host的,在多CPU之间进行负载均衡的
  时候不会转移cache hot的进程。

* sched_nr_migrate
  在多CPU情况下进行负载均衡时,一次最多移动sched_nr_migrate个进程到另
  一个CPU上。

2012年8月4日星期六

关于linux内核抢占的一点思考

偶然看了一下rhel6.2系统内核中处理软中断的内核线程,很意外的产生了一点困
惑,这是ksoftirqd线程的主循环:

1    while (!kthread_should_stop()) {
2        preempt_disable();
3        if (!local_softirq_pending()) {
4            preempt_enable_no_resched();
5            schedule();
6            preempt_disable();
7        }
8
9        __set_current_state(TASK_RUNNING);
10
11        while (local_softirq_pending()) {
12            /* Preempt disable stops cpu going offline.
13               If already offline, we'll be on wrong CPU:
14               don't process */
15            if (cpu_is_offline((long)__bind_cpu))
16                goto wait_to_die;
17            do_softirq();
18            preempt_enable_no_resched();
19            cond_resched();
20            preempt_disable();
21            rcu_sched_qs((long)__bind_cpu);
22        }
23        preempt_enable();
24        set_current_state(TASK_INTERRUPTIBLE);
25    }

假设在23行执行完之后,有人试图唤醒这个线程,此时,线程还处于
TASK_RUNNING的状态,所以什么都不会发生。然后,在第24行,线程将自己设置
成了TASK_INTERRUPT状态,在执行第24行之后,线程被抢占了,那么,它在
TASK_INTERRUPT状态下被抢占,除非再次有人唤醒它,它岂不是再也返回不了了?
这样,不就丢失了一次唤醒吗?

这让我很困扰,于是,我自己写了个测试程序,启动一个内核线程,然后让它把
自己设置成TASK_INTERRUPTIBLE的状态,再进行几秒钟的忙循环。正常来说,执
行几秒钟的忙循环的话,肯定会被抢占了。然后我看它还能不能再被调度上来。
结果意外的发现rhel6的内核编译时是配置成不可抢占的(后来发现rhel5也这
样),我那个单核的虚拟机一执行忙循环就hang住。于是,重新编译了一个可抢
占的内核跑起来。结果发现,执行忙循环后,还是能被调度上来的。但如果我不
执行忙循环,而是调用schedule()函数,那么,除非被唤醒,否则就不能再被调
度上来了。

用systemtap跟踪了一下我的内核线程进入schedule()函数时的一些信息,结果
发现如果我主动调用schedule()函数,在进入schedule()函数时,thread_info
中的preempt_count的值是0x00000005,而如果在执行忙循环时被抢占调用
schedule函数时,preempt_count的值是0x10000005。这个最高位1在内核中被定
义为PREEMPT_ACTIVE。

原来,每当在抢占点上执行schedule函数时,这个标志会被设置,比如,从中断
返回时,调用:
retint_kernel
-> preempt_schedule_irq
   -> schedule

在preempt_schedule_irq函数中,就会调用这几行代码:

        add_preempt_count(PREEMPT_ACTIVE);
        local_irq_enable();
        schedule();
        local_irq_disable();
        sub_preempt_count(PREEMPT_ACTIVE);

设置PREEMPT_ACTIVE后,再调用schedule()函数,然后再清除PREEMPT_ACTIVE标
志。

而在schedule()函数中,有这样一段代码:

    if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
        if (unlikely(signal_pending_state(prev->state, prev)))
            prev->state = TASK_RUNNING;
        else
            deactivate_task(rq, prev, DEQUEUE_SLEEP);
        switch_count = &prev->nvcsw;
    }

prev就是当前要被调度下cpu的进程。prev->state为0表示TASK_RUNNING的状态。
如果进程的状态不是TASK_RUNNING并且PREEMPT_ACTIVE标志没有被设置,再判断进程是否有pending的信号,如果有,就把进程状态设置成TASK_RUNNING状态,
如果没有pending的信号,就把进程从RUNNING的进程队列里拿下来。

因此,逻辑关系是这样的:
如果PREEMPT_ACTIVE被设置了,说明进程是由于内核抢占被调度下CPU的,这时不
把它从RUNNING的队列里移除,如果进程不是由于内核抢占被调度下来的,看它
有没有未处理的信号,如果有的话,也不把它从RUNNING的队列里移除。只有再
上述两种情况都为假的情况下,进程才会被从RUNNING的队列里移除。

这就解释了为什么内核线程把自己设置成TASK_INTERRUPTIBLE状态之后,只要不
是主动调用schedule()函数,而是被抢占调度下cpu的,它就还会获得机会运行。

2012年7月27日星期五

linux内核的cfq IO调度算法的tuning参数

                              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类型的。

2011年11月10日星期四

cfq io调度算法简介

本文以rhel5.6所使用的2.6.18内核进行分析。

1 cfq用到的几个数据结构
~~~~~~~~~~~~~~~~~~~~~~~~
  在cfq中,进程被按照优先级分组。cfq尽量优先处理高优先级组中的请求,同
  时也避免低优先级组中的请求被饿死。一个进程可能同时向多个不同的块设备
  提交io请求,而一个使用cfq调度算法的块设备又要处理多个进程中传下来的
  请求,并将它们分组。所以,cfq使用下面这些数据结构分别描述进程,优先
  级组,以及一个cfq块设备。

1.1 struct io_context
======================
   每个进程都有一个io_context结构体,从其定义中包含
   struct as_io_context *aic;
   和
   struct rb_root cic_root;
   这两位来看,它是专为as和cfq两个io调度算法准备的,在cfq中,它是
   struct cfq_io_context的基类。

1.2 struct cfq_io_context
==========================
   cfq_io_context是cfq中为每个进程分配的结构体,继承自io_context。每个
   进程都只有一个io_context,但它同时向多少个使用cfq调度算法的块设备提
   交io请求,就会有多少个cfq_io_context,这些个cfq_io_context被组织在
   一个红黑树中,树根是io_context中的cic_root,cfq_io_context中的"void
   *key"位用作红黑树的键值。由于每个cfq_io_context对应一个使用cfq调度
   算法的块设备,所以实际上cfq使用struct cfq_data结构体的地址作为键值,
   每个使用cfq算法的块设备都有唯一的一个struct cfq_data结构体。

1.3 struct cfq_queue
=====================
   当多个进程向同一个块设备提交io请求的时候,cfq会对进程按照优先级进行
   分组,进程的优先级信息存储在进程结构体的"unsigned short ioprio"位中,
   如果该位没有进行设置,cfq按照进程的nice值计算出一个优先级。默认共有
   8个优先级,对于每个优先级组,使用一个cfq_queue结构体进行表示。

1.4 struct cfq_data
====================
   每个使用cfq调度算法的块设备都有一个cfq_data结构,保存在struct
   elevator_queue的void *elevator_data位中。

1.5 struct cfq_rq
==================
   每个request都有一个cfq_rq,保存在request的void *elevator_private位
   中。

2 cfq_set_request函数
~~~~~~~~~~~~~~~~~~~~~~
  每当有一个新的io请求提交之后,电梯算法都会调用cfq_set_request函数让
  cfq为该请求分配必要的资源。
  首先调用cfq_get_io_context函数获取一个struct cfq_io_context结构,如
  果没有的话cfq_get_io_context函数会分配一个新的。
  接下来看cfq_io_context的"struct cfq_queue *cfqq"位有没有包含一个
  struct cfq_queue,如果没有的话就调用cfq_get_queue函数。
  cfq_get_queue函数计算当前进程的io优先级,并检察当前块设备的struct
  cfq_data结构中有没有对应该优先级的cfq_queue,有的话就返回,没有的话
  就分配一个新的。然后调用cic_set_cfqq函数让当前进程的cfq_io_context指
  向该cfq_queue。
  接下来分配一个新的对应于当前请求的struct cfq_rq结构。

3 cfq_insert_request函数
~~~~~~~~~~~~~~~~~~~~~~~~~
  调用完cfq_set_request函数后,电梯算法会调用cfq_insert_request将新提
  交的请求插入到cfq的数据结构中。
  首先检查cfq_queue的优先级是否改变,如果改变将相应的信息更新。然后将
  该请求对应的cfq_rq插入到以cfq_queue的"struct rb_root sort_list"为根
  的红黑树中。将请求按照提交时间的先后顺序放到cfq_queue的fifo链表上,
  如果该请求是可合并的,则将请求放到cfq_data的哈希表中,在合并请求时,
  会用到该哈希表。最后,调用cfq_crq_enqueued函数更新一些时间戳以及统计
  信息。

4 cfq_dispatch_requests函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  每当电梯算法要补充一些请求到请求队列上的时候,会调用
  cfq_dispatch_request函数。
  首先调用cfq_select_queue选择一个优先级队列,然后调
  用__cfq_dispatch_requests函数将该优先级队列上的一部分请求放到请求队
  列上。
  选择优先级队列时,总是从最高等级的优先级队列开始选择,但每个等级都有
  一个时间片,如果该等级的时间片到期,则选择下一个等级的队列。

5 merge
~~~~~~~~

5.1 cfq_merge函数
==================
   电梯算法调用cfq_merge函数判断一个新的请求是否能和以前的请求合并。
   首先判断是否能进行后向合并。cfq_data中有一个哈希表,储存了所有可以
   合并的请求,并且以请求的结束扇区号作为键值。所以,以当前请求的起始
   扇区号作为键值进行搜索,如果能够搜到一个请求,则说明搜到的请求的结
   束扇区号和当前请求的起始扇区号相等,可以进行后向合并。
   如果没有找到能够进行后向合并的请求,则尝试寻找是否有能进行前向合并
   的请求。以当前请求的结束扇区号为键值,在与当前请求的io优先级相等的
   cfq_queue的红黑树中寻找。由于该红黑树中的成员是以请求的起始扇区号为
   键值的,如果找到,说明可以进行前向合并。
   cfq_merge的返回值会告诉调用它的函数是可以进行前向合并,还是后向合并,
   还算不可以合并。如果可以合并,会将可用来合并的请求放到struct
   request **req中返回。

5.2 cfq_merged_request函数
===========================
   所谓合并,就是将一个新传递进来的bio放到一个以前的request中。实际的
   合并操作是在ll_rw_blc.c和elevator.c中完成的。在合并完成之后,电梯算
   法会调用cfq_merged_request函数让cfq进行一些必要的更新。由于进行了合
   并,request的起始扇区号和结束扇区号可能会发生变化,而cfq内部所用的
   哈希表以及红黑树是以这两个值作为键值的。所以,cfq_merged_request的作
   用就是检验这两个值是否变化,若变化了则以新的键值放置相应的数据结构
   成员