多处理器下的硬实时操作系统研究

实现迁移

当非RT0任务调用了函数artis_request_for_migration()时，它不能直接把自己插入到其他处理器的运行队列当中，因为这样就会造成多处理器在同一时间运行同一任务的情况，所以在ARTiS系统中，是通过与当前处理器上的下一个任务来插入迁移任务的，总的来说可以分为三步：首先，迁移进程会调用artis_request_for_migration()，设置迁移标志，并将自身的亲和CPU设置为本地CPU，然后使自身再次进入可抢占状态，调用调度函数。然后，新调度的任务将执行函数artis_complete_megration()，该函数将调用函数 finish_task_swith()完成调度，选择一个非实时处理器把迁移任务插入到其上的RT-FIFO队列，并通过产生一个进程间的中断信号来强制目标处理器产生一轮新的调度。最后，目标处理器上的调度程序将通过调用函数artis_fetch_migration()从RT-FIFOs队列中取出迁移任务。

2.2 负载平衡机制

在ARTiS系统中，当涉及对称处理器之间的负载平衡时，直接沿用原有的负载平衡机制。而对于不对称处理器上的负载平衡，则通过修改原linux的负载平衡机制来实现。由于非实时任务从实时处理器到非实时处理器的迁移是强制的。所以不存在负载平衡的问题，所以这里只考虑如何将非实时处理器上的非实时任务迁移至实时处理器。可以从两个方面进行分析：一个是确定迁移的目标处理器，一个是确定要迁移的任务。

确定迁移的目标处理器

CPU的负载指的就是该CPU运行队列的长度（在该CPU上等待运行的程序个数），Pairing policy首先计算各个CPU运行队列的长度，然后把负载最重的CPU上的任务分配到负载较轻的CPU上。当各个CPU处理的都是非实时的任务时，该策略则运作的很好，因为非实时的任务将平分CPU的时间，但是在有实时任务的情况下，由于实时任务具有绝对的优先级，它将独占CPU，所以不能再简单的只用运行队列的长度来衡量负载的大小。

在ARTiS系统中，在原有的策略上，添加了一个由实时任务的运行时间构成的负载参数，这时将通过公式L× 1/1−RT (L表示某个CPU上非实时任务的个数，RT表示实时任务需要占用CPU的时间)计算各个处理器上的负载。例如：假设在双CPU的情况下有6个任务（包括实时任务），实时任务需占用CPU时间的3/4的，对于通常的分派策略，一个处理器分三个任务，那么在一个处理器上，每个非实时任务将占用1/3的CPU 时间，而在另一个处理器上，非实时任务占用的时间只有1/8，显然分配很不均等。在ARTiS中，它首先会统计每个处理器上的非实时任务的个数，并利用公式L× 1/1−RT计算出每个处理器的负载，然后选择负载较轻的处理器作为目标处理器，这时每个非实时任务将都会占有1/4的处理器时间，达到了负载均衡的目的。参照下图：

确定迁移的任务

当确定了迁移的处理器之后，接下来要确定的就是要迁移的任务。选择的标准就是尽量选择那些可以在实时处理器上可以较长保持可抢占状态的非RT0任务，如果一个非RT0任务迁移的频率过高，那么就会造成非RT0任务在实时处理器与非实时处理器之间推来推去，即所谓的乒乓效应。这样不仅没有达到负载平衡的目标，反而降低了改任务执行的效率。

为了避免乒乓效应，ARTiS采用统计的方式来预估一个任务可能的迁移频率（在任务属性中添加两个变量，分别用来保存迁移请求的时间间隔平均值和上一次迁移发生的时间），并通过该预估的频率与当前迁移任务发生的时机相比较，由此来决定当前的任务是否可以迁移。对于一个请求迁移的任务，由于它的请求点有可能发生在预估请求之前，也有可能发生在预估请求之后，所以分两种情况：当请求点发生在预估点之前时（如图2中的第五个迁移点所示），如果它离预估的迁移点很近，那么说明它马上又要迁移了，所以应当被阻止，而如果离预估点较远的话（如图2中的第4个迁移点）。同样对于请求点发生在预估点之后的迁移请求，如果离预估点很近的话（如图2中的第一个迁移点），那么认为它刚刚发生过迁移，所以不允许短时间内再次迁移，所以也会被阻止，而与之较远的（3）、（4）迁移点则可进行迁移。由此可见，在设计的同时设定的偏差范围将直接影响ARTiS的性能，所以应当通过多次的试验来选取一个合适的偏差。