Re: [microblaze-uclinux] Workaround-Patch for priority inversion in pthread lib of kernel 2.6

[pcolodron@xxxxxxxx]

Hi John,

I have succesfully ported a PetaLinux v0.30 system in my Xilinx board.  
However, I think I am experiencing a priority inversion problem with a  
multi-threaded application (my system completely hangs and the console  
do not even receive the keystrokes).

I have looking at this post and you mentioned that the only sensible  
way to fix priority inversion was to implement a priority inheritance.  
I have been reading some things about this issue but I can not figure  
out which changes shoud I make to apply this priority ineritance to my  
system.

Should I modify the libpthreaed in order to change the way in which it  
locks the resources or can I scalate the thread priority in the user  
application? Could you give some hints about how to implement priority  
inheritance?

Thank you very much for your help in advance.

Kind regards,

Pablo Colodron




Hi Falk,

On Tue, Apr 21, 2009 at 8:34 PM, Brettschneider Falk
<fbrettschneider@xxxxxxxxxxxxxxx> wrote:

> I experienced hangs of PetaLinux (kernel 2.6) because my  
> multi-threaded user app uses SCHED_RR and runs into thread-inversion  
> problems.
> This is a known problem I've already seen in older uClinux releases  
> for the microblaze (with kernel 2.4).
>
> The actual problem is based in the pthread library itself. Once it  
> was discussed here:  
> http://readlist.com/lists/uclinux.org/uclinux-dev/0/3487.html and  
> the final conclusion was that the problem will be fixed with kernel  
> 2.6 together with the NPTL library instead of the pthread library.  
> Unfortunately, pthreads are still used, that's why the problem is  
> still not solved.
>
> My attached patch doesn't fully solve the problem, but fixes the  
> thread-inversion for single-CPU-architectures which I suppose most  
> microblaze systems are. That is why I framed the changes with #ifdef  
> CONFIG_SMP.
>
> Please, can you apply it at least to the PetaLinux distribution?

Unfortunately there's a pretty fundamental problem with this patch -
including asm/system.h, and calling local_irq_disable() in library (==
userspace) code, is, well, evil :-(  It also won't work on any CPU
that implements privileged instructions, which includes microblaze
when the MMU is enabled (not that we are using uClibc in that case,
but it's a step in the wrong direction).

Another minor nitpick is that the kernel option CONFIG_SMP is not
supposed to be tested in userspace/library context, only in the
kernel.  The fact that it works is just an artifact of how the
original uClinux-dist build environment is held together.

AFAIK the sensible way to solve priority inversion is to implement
priority inheritance - basically when a thread blocks on a resource,
you temporarily escalate the holding thread to the same or higher
priority, until it releases the resource.  This allows the holding
thread to complete its use of the resource and free it up so the
higher priority thread gets a turn on the CPU.

I seem to recall looking at this in a pthreads context years ago, and
the implementation didn't look too horrific. No doubt there are corner
cases, but it's got to be cleaner than doing IRQ disabling in
userspace.

Sorry for such a negative response, but it's just not something we can
reasonably add in its current form.

My hope is that we'll see progress on NPTL for MicroBlaze in the
not-too-distant future - in the meantime this patch will of course be
archived and found by anyone searching for the right keywords.

Cheers,

John
--
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/