Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 | From | Mark_H_Johnson@raytheon ... | Date | Thu, 4 Nov 2004 10:53:58 -0600 |
| |
>> I can set those as well but then I'd probably have to follow with >> the X server and everything else in the chain. The starvation problem >> ripples across the system. > >X should be scheduled on the other CPU just fine. Only per-CPU kernel >threads (which are affine to their particular CPU) are affected by this >problem - ordinary tasks not. I.e. the system threads that have /0 and >/1 in their name. In theory you should not even need to chrt the hardirq >threads, those should schedule fine too. Perhaps "should be fine" but the test I just ran indicates otherwise. The kernel is -V0.7.7 plus the patch you just sent me. All IRQ and /# tasks were set to RT priority 99.
Started the X test and the display locked up almost immediately while ping responses continued to flow on a regular basis. After several seconds I could see the display update / move the mouse & then the display locked up again. It went back and forth a couple cycles and did not get unstuck until the RT audio application quit (over 250000 samples).
I will let it run to see if I can reproduce the deadlock or if the symptoms change with one of the other tests.
--Mark H Johnson <mailto:Mark_H_Johnson@raytheon.com>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |