Messages in this thread | | | Date | Tue, 5 Apr 2005 11:25:55 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00 |
| |
On Tue, 5 Apr 2005, Ingo Molnar wrote:
> > * Esben Nielsen <simlo@phys.au.dk> wrote: > > > > Now the question is, who will fix it? Preferably the maintainers, but I > > > don't know how much of a priority this is to them. I don't have the time > > > now to look at this and understand enough about the code to be able to > > > make a proper fix, and I'm sure you have other things to do too. > > > > How about adding a > > if(rt_task(current)) { > > WARN_ON(1); > > mutex_setprio(current, MAX_PRIO-1) > > } > > ? > > > > to find all calls to yields from rt-tasks. That will force the user > > (aka the real-time developer) to either stop calling the subsystems > > still using yield from his RT-tasks, or fix those subsystems. > > i've added this to the -43-08 patch, so that we can see the scope of the > problem. But any yield() use could become a problem due to priority > inheritance. (which might eventually be expanded to userspace locking > too) > Any calls to non-deterministic subsystems breaks the real-time properties. yield() is certainly not the only problem. Code waiting for RCU-completion or whatever is bad too. Calling code like that from RT-tasks or calling them while having locks shared with RT-tasks is just bad. Anyone knowing about RT development _has_ to know that. Putting warnings and traces into the kernel is a nice feature.
Static code analyzes would also help quite a bit. What about having a new attribute "nonrt" for functions and locks? yield() and syncronize_kernel() are certain candidates. Any function having nonrt operations are marked nonrt. Any lock becomes held while doing a nonrt operation is marked nonrt. Taking a nonrt lock is a nonrt operation. (Might end up marking the whole kernel nonrt....)
Esben
> Ingo
- 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/
| |