- 论坛徽章:
- 0
|
创建了一个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微秒以内或是更小?
|
|