唤醒进程（wake_up_process）到进程真正执行延迟较大

noted2011

创建了一个Linux 实时进程A，优先级是99，实时调度策略SCHED_FIFO，该进程绑定到core1上。
该进程的重要代码：
while(1) {
    ret = syscall(333,osp_pcb->osp_inst,0);
}


syscall的实现：

SYSCALL_DEFINE2(wait_wakeup,unsigned int ,a , unsigned int, b)
{
       if(osp_int_wake_reg==NULL)
       {
               return -EPERM;
       }

       osp_int_wake_reg(a,b,current);

       __set_current_state(TASK_INTERRUPTIBLE);
       schedule();

       __set_current_state(TASK_RUNNING);
       osp_int_wake_unreg(a,b,current);

       if(signal_pending( current ))
       {
               return -EINTR;
       }

    return 0;
}


在每1毫秒来一次的硬中断ISR里，用wake_up_process去唤醒该进程A，该中断亲和到core0，也就是绑定到core0上。

整个流程：首先是进程A执行，把当前进程赋值给进程A的task_struct，把当前进程设置为TASK_INTERRUPTIBLE状态，接着让出CPU，等到每1毫秒的中断到来时，唤醒进程A。
但是发现，从1毫秒中断到来，然后唤醒进程A，再到进程A再次调度执行的这段时间，有的时候（万分之四）延迟较大，大约有800微秒，也就是0.8毫秒。LInux kernel版本是linux 2.6.32.12,打了实时patch。
初步怀疑是：当进程被wake_up_process等函数改变为执行可能的时候，被连接入RUN队列。但只是仅仅连入RUN队列的话，这个无论这个进程的优先度多高都不会获得CPU。需要等到调度器选中它，cpu才开始执行。
毕竟Linux 提供的实时调度是软实时，并不能保证像硬件实时那样完全可靠。

请问一下，有没有好的解决办法，让这个延迟控制到100微秒以内或是更小？

mordorwww

直接轮询试试

瀚海书香

回复 1# noted2011

但是发现，从1毫秒中断到来，然后唤醒进程A，再到进程A再次调度执行的这段时间，有的时候（万分之四）延迟较大，大约有800微秒，也就是0.8毫秒。LInux kernel版本是linux 2.6.32.12,打了实时patch。
初步怀疑是：当进程被wake_up_process等函数改变为执行可能的时候，被连接入RUN队列。但只是仅仅连入RUN队列的话，这个无论这个进程的优先度多高都不会获得CPU。需要等到调度器选中它，cpu才开始执行。
毕竟Linux 提供的实时调度是软实时，并不能保证像硬件实时那样完全可靠。

手头没有Ingo real的代码。从主树的代码看，wake_up的确是设置state，并放到runqueues中，需要等待调度的

如果能接收该进程独占一个核心的话，使用类似cpu_relax()的忙等或许可行

   

noted2011

回复 2# mordorwww

你说的直接轮询是指什么，是用轮询代替syscall吗？不太明白。之前syscall这块，是用epoll和等待队列实现的，但是实时性得不到保证，延迟比这还大。

   

noted2011

回复 3# 瀚海书香

进程A所在的core上，还有同等优先级的实时进程B，还有其他的普通进程，不能独占。
   

humjb_1983

1ms的硬中断是指时钟中断么？
建议在唤醒A之后，手工设置下NEED_RESCHED标记，这样，在中断返回的后，就有调度的时机点，此时A进程的优先级够高，按理应能得到调度。
另外，也不排除中断和软中断的影响，RT补丁中有中断和软中断线程化的补丁，不知是否有打。

noted2011

humjb_1983 发表于 2014-02-14 13:02
1ms的硬中断是指时钟中断么？
建议在唤醒A之后，手工设置下NEED_RESCHED标记，这样，在中断返回的后，就有 ...

1ms的硬中断是FPGA产生的，经过cpld透传给CPU的外部中断。RT补丁的中断线程化打上了，除了三个在core 0上的外部中断，人为设置为不中断线程化。进程A所在的core 1上的中断都中断线程化了。
按照你的建议，设置了NEED_RESCHED标记。
具体代码：
wake_up_process(osp_task_structs[cell_id][0]);
set_tsk_need_resched(osp_task_structs[cell_id][0]);


但是，延迟仍然很大，800多微秒，没有改观。

kkddkkdd11

noted2011 发表于 2014-02-14 13:44
1ms的硬中断是FPGA产生的，经过cpld透传给CPU的外部中断。RT补丁的中断线程化打上了，除了三个在core 0 ...

挂接一个定时器中断上，然后中断处理过程中轮询
虽然 进程开发稳定些，开发容易些...

noted2011

kkddkkdd11 发表于 2014-02-14 14:16
挂接一个定时器中断上，然后中断处理过程中轮询
虽然 进程开发稳定些，开发容易些...

定时器中断本身的精度就不高，系统都给中断线程化，跟实时进程的优先级都一样。中断处理要求尽量快，一般不建议在中断处理过程中去轮询。
还有，我们产品的上层应用比较复杂，是协议栈，有很多进程，进程里有若干个线程，不方便大改。

kkddkkdd11

noted2011 发表于 2014-02-14 15:00
定时器中断本身的精度就不高，系统都给中断线程化，跟实时进程的优先级都一样。中断处理要求尽量快，一 ...

现在 很多高端网卡 就是走的 软中断 napi轮询
然后可以配合 mmap 自己解析协议
并没有 非要走int80 这种玩法：）