On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
