[进程管理] 唤醒进程（wake_up_process）到进程真正执行延迟较大 [复制链接]

noted2011

论坛徽章:: 0

21楼 [报告]

发表于 2014-02-16 13:14 |只看该作者

junnyg 发表于 2014-02-14 17:54
wake_up_process中会调用check_preempt_curr_rt检查是否能抢占当前任务，如果可以抢占，任务在其他核的，会 ...

之前描述地还不是很详细，再补充一下。
整个流程：首先是进程A执行，把当前进程赋值给进程A的task_struct，把当前进程设置为TASK_INTERRUPTIBLE状态，接着让出CPU，等到每1毫秒的中断到来时，唤醒进程A。1ms中断在core0上，进程A在core1上。

core0上有3个外部中断，都是硬中断，打了实时补丁，其他的中断都中断线程化了。core0上的3个外部中断比其他中断（比如定时器中断）优先级都高，这三个外部中断都是1ms来一次，并且时间上是错开的，分别相隔有500多微秒和170多微秒，不是相互干扰，也做了统计的，没有丢中断的现象。目前测试的时候，core0上只开启了一个外部中断，1ms来一次。

core1上只有定时器中断，linux系统自带的，但也都中断线程化了。core1上的进程A的优先级最高，是99。
该CPU有8个core，网卡中断，串口中断等等都绑定到core7上。

进程A不能独占一个core，真实的业务还有一个同样高优先级的实时进程B，还有一些低优先级的实时进程以及普通进程，更确切地说，进程A和B都是线程，为了简单的描述这个问题，简化了。测试的时候，core1上只有进程A，其他的实时进程只有linux系统自带的。

我们是在core0 1ms中断 ISR里去唤醒进程A，而进程A是在core1上，是显示调用 schedule()，主动放弃cpu。也就是说，是在core0上的中断服务程序里，去唤醒core1上的进程A。正如你所说，好像不应该达到800微秒那么大，但是，这个延迟不是每次都那么大，出现的概率是万分之四左右，跑了12个小时的结果。而且是core0上唤醒core1上的进程。我怀疑linux2.6.34.12这个版本的linux实时调度性能就这样，偶尔的延迟就这么大，毕竟是软实时，不是硬实时。

SunOS 5.0延迟也有0.5毫妙，500微妙，具体描述及链接：

Dispatch Latency

The most significant element in scheduling behavior for real-time applications is the provision of a real-time scheduling class. The standard time-sharing scheduling class is not suitable for real-time applications because this scheduling class treats every process equally and has a limited notion of priority. Real-time applications require a scheduling class in which process priorities are taken as absolute and are changed only by explicit application operations.

The term dispatch latency describes the amount of time it takes for a system to respond to a request for a process to begin operation. With a scheduler written specifically to honor application priorities, real-time applications can be developed with a bounded dispatch latency.

able 8-1 Real-time System Dispatch Latency with SunOS 5.0 through 5.8
Workstation    Bounded Number of Processes                                           Arbitrary Number of Processes
SPARCstation 2    <0.5 milliseconds in a system with fewer than 16 active processes    1.0 milliseconds
SPARCstation 5    <0.3 millisecond                                                    0.3 millisecond
Ultra 1-167    <0.15 millisecond                                                 <0.15 millisecond

Tests for dispatch latency and experience with such critical environments as manufacturing and data acquisition have proven that SunOS 5.8 is

http://docs.oracle.com/cd/E19455 ... rt-21297/index.html

使用LWT模型，在用户态做调度？
这个不太了解，查了一下，只有大概的介绍，没有具体使用。可否告诉一下关于如何使用LWT模型？
还有，我们的这个业务都是基于1ms中断的，在1ms中断没有到来之前，要等待，并要让出cpu去干其他的事情。1ms中断到来了，内核态要马上通知用户态开始干活。