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

[Esben Nielsen <simlo@phys.au.dk>]

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/