rt-migrate-test测试失败分析

测试环境：
linux-3.2.39-rt59
glibc2.6 
freescale p2020单板 e500双核


rt-migrate-test


ftrace function追踪的日志片段
trace--2--simple.txt
实时线程A，B，C。线程C优先级最高，线程B次之，线程A优先级最低。
还有一个主线程M，线程M的优先级比线程C还高。
线程A,B,C均循环执行如下代码:
pthread_barrier_wait(&start_barrier);
busy_loop();
pthread_barrier_wait(&end_barrier);

rt-migrate-test测试失败时，线程B从start_barrier处逃出时，线程A已经执行完成busy_loop()！
根据rt scheduler的设计行为，线程B执行完busy_loop之前，线程A是不应该执行完busy_loop的。
那为什么实际情况下与设计不符呢？


通过ftrace追踪函数调用，发现出错的那次测试是这么一个情况：
线程M，线程A，线程C已经进入start_barrier，线程B最后进入start_barrier。
线程M和线程A在cpu0上，线程B和线程C在cpu1上。
线程B最后一个进入start_barrier后，解锁M，C，A。
由于线程A正在cpu0上运行，因此线程A最先逃出start_barrier。线程M，线程C分别扔到了cpu0和cpu1的运行队列上。
cpu0上线程A在运行，线程M在rq0上；cpu1上线程B在运行，线程C在rq1上。
线程M和线程C都有机会抢占！事实上也是如此，很快，线程M抢占线程A，运行在cpu0上；线程C抢占线程B，运行在cpu1上。
根据rt scheduler的push算法，线程B应该被推送到cpu0上，但事实上却没有！！！为什么？？？

仔细查看ftrace记录，我找到了原因，线程B在唤醒线程C之前，调用了migrate_disable，也就是禁止迁移！
因此，线程B不会被推送到cpu0，只能在cpu1上等待。违反了SWSRPS（system wide strict realtime priority schedule）！！！