Xin Xie wrote: > However my concern is more related to the context switch timing (the > user process get scheduled after IRQ happens), the worst case > measurement under the ping flood is the 24mS. Is there any way to > schedule a user process more quickly after IRQ happened under the heavy > system load? I know I can push the user process into the kernel space to > get the fast response time, but........
You should be able to set the process into a real-time scheduling class, then, provided no other processes are in the same or higher class, it should be scheduled without a long delay after the interrupt. See sched_setscheduler() and/or pthread_setschedparam(). If your delay is caused by non-process contexts in the kernel (such as network packet processing, some of which happens outside interrupts), have a look for the RT-preempt patches, which are ongoing development. > Also can anyone tell me which features 2.6.22 uClinux kernel have > improved in the regards of soft real-time abilities? I understand the > CFS maybe has a big impacts on the desktop tasks performance, but I am > not too sure if it has impacts on embedded system running uClinux. If you want the best available soft real-time on 2.6.22, there's a few patches from various people that aren't in standard kernels. The only one I know about for 2.6.2x is Ingo Molnar et al's RT-preemption patch set, which moves things like interrupts and soft interrupts into their own process contexts, so high real-time priority processes can still run ahead of them if appropriate, with priority inheritance on locks to prevent deadlocks, and which makes more locked regions in the kernel pre-emptible by higher priority processes to reduce the time in critical sections. -- Jamie _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
