wake_up_process无法换醒进程，用什么工具来跟踪LTTng vs Ftrace？
本帖最后由 wLiu2007 于 2015-02-11 23:33 编辑系统有一个1ms的外部硬件中断送过来，在1ms中断处理函数(上半部）里面去换醒用户态实时进程；即
hw_1ms_isr()
{
其它处理代码；
wake_up_process(AAA);
}
进程AAA的写法：
AAA()
{
while(1)
{
wait_1ms_wakeup(); //这个函数就是系统调用，设置task状态为TASK_INTERRUPTIBLE，执行schedule
处理引用逻辑；
}
}
目前有个问题，当系统负载不高的时候，工作很正常，每个1ms用户态的进程AAA都能够被换醒，被执行；
可当系统负载变高以后，hw_1ms_isr调用了wake up process函数，但是用户进程AAA存在周期性的不能被换醒；周期是1s时间，每1s时间会有连续的20~50个无法换醒；
这个问题比较奇怪，进程AAA是一个实时任务，调度测试为SCHEDULE_FIFO，优先级是所有任务中最高的，按说hw_1ms_isr上半部处理完了，然后再处理softirq之后，进程应该能够马上被换醒，为什么会无法换醒？而且周期还是1s时间
想请教下各位：
1.中断里面调用了wake up，但是进程无法换醒，这段时间cpu在做什么事情，用什么trace工具可以分析，LTTng 还是 Ftrace，没有用过这2个工具，两个工具有什么区别？
2，内核里面有什么周期是1s的事情吗，而且处理啊时间需要几十个ms的？ 负载高时具体是些什么负载~
虽然你的进程优先级高，但会被中断，如果还有其它类似网络的负载(依赖软中断处理)，那就不能保证及时调度了。
linux本身就是非实时的，难以保证实时性。
本帖最后由 wLiu2007 于 2015-02-12 10:29 编辑
补充下：
板子是Powerpc双核的，1.2GHz，负载是网卡收包也就100Mbps网卡收包，然后用户态进程对包做处理，
系统打了实时补丁，网卡收包的软中断都线程化了，且优先级比这个要换醒的进程还低 回复 3# wLiu2007
好久没来了。中断开销也不少呀，还由换醒开销。 1ms来说对LInux是不能满足的，你别去想了。 看来Powerpc双核的，1.2GHz的性能不是很强哈. 1ms之内处理硬中断，再由硬中断**用户进程，这中间涉及到进程切换的开销就很大了。
未知楼主的系统负载高是什么导致的？用mpstart -P ALL 1看下哪个方面呢，你的进程优先级那么高，影响到它的很可能是 humjb_1983 说的软中断了。
觉得这并不是实时，应该考虑换方案。
在hw中断下半部收到消息就入队列，用户的进程监听队列，缓冲+并行。你认为进程很关键，优先级就还是FIFO的，让系统多照顾照顾，但是必须隔一段时间就主动睡眠一下让出cpu。
页:
[1]