Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

Esben Nielsen
2005-04-05T09:30:52Z

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