![]() | |||||||||||||
Messages in this thread |
On Sat, 2004-10-09 at 17:38, stefan.eletzhofer@eletztrick.de wrote: > On Sat, Oct 09, 2004 at 03:30:27PM -0400, Lee Revell wrote: > > On Sat, 2004-10-09 at 17:26, stefan.eletzhofer@eletztrick.de wrote: > > > On Sat, Oct 09, 2004 at 02:30:28PM -0400, Lee Revell wrote: > > > > On Sat, 2004-10-09 at 13:41, Karim Yaghmour wrote: > > > > > Sven-Thorsten Dietrich wrote: > > > > > > - Voluntary Preemption by Ingo Molnar > > > > > > - IRQ thread patches by Scott Wood and Ingo Molnar > > > > > > - BKL mutex patch by Ingo Molnar (with MV extensions) > > > > > > - PMutex from Germany's Universitaet der Bundeswehr, Munich > > > > > > - MontaVista mutex abstraction layer replacing spinlocks with mutexes > > > > > > > > > > To the best of my understanding, this still doesn't provide deterministic > > > > > hard-real-time performance in Linux. > > > > > > > > Using only the VP+IRQ thread patch, I ran my RT app for 11 million > > > > cycles yesterday, with a maximum delay of 190 usecs. How would this not > > > > satisfy a 200 usec hard RT constraint? > > > > > > I think the keyword here is "deterministic", isn't it? > > > > Well, depends what you mean by deterministic. Some RT apps only require > > an upper bound on response time. This is a form of determinism. > > Yes. But can you give that upper bound "a priori", that is w/o doing > measurements with your application? > Yes. The upper bound on the response time of an RT task is a function of the longest non-preemptible code path in the kernel. Currently this is the processing of a single packet by netif_receive_skb. AIUI hard realtime is about bounded response times. How does this not qualify? Lee - 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/ | ||||||||||||
| Last update: 2005-03-22 14:06 [from the cache] ©2003-2008 | |||||||||||||