Clarify DFLT and PRIO "wait_operation" field in rtems_monitor_task_dump() in pthreads in 4.12

dufault at dufault at
Fri Sep 30 20:45:30 UTC 2016

> On Sep 30, 2016, at 08:05 , Sebastian Huber <sebastian.huber at> wrote:
> On 30/09/16 12:35, dufault at wrote:
>>> On Sep 30, 2016, at 01:49 , Sebastian Huber 
>>> <sebastian.huber at 
>>> <mailto:sebastian.huber at>> wrote:
>>> Hello Peter,
>>> On 30/09/16 00:13, Peter Dufault wrote:
>>>> I’m moving an older application to 4.12 and having performance 
>>>> issues compared to “4.11” (aka “4.10.99”) from around 2012.
>>> what do you mean with performance issues?
>> The version running in the field is running a 10KHz servo using the 
>> “beatnik” BSP with about a 50% CPU load (based on time-stamps from the 
>> powerpc time counter at certain times during the servo loop collected 
>> at the frequency, so I can plot them and see where there are any funny 
>> bursts in the different phases of the work, interrupt at 10KHz, very 
>> high priority thread (commute) at 10KHz, lower priority thread run 
>> lest often (servo, 5KHz), etc ).  In the version I’ve just built it’s 
>> finishes with the final phase at 90% of the 10KHz period, and fails 
>> after a short time.  I’ve lowered the interrupt rate to 6KHz to get it 
>> to even run reliably.
> Are you able to get a histogram of the times spent in each function for 
> both version?
> Compiler and configuration options are the same? How did you configure 
> your BSP? Do both versions use the AltiVec unit?

Same compiler and configuration options?  Well, no, we’re talking 2011 4.10.99 versus last weeks master.   Neither version disables the AltiVec unit so the usage may be based on the compiler version.

I’ve rolled back to November 2011 and will work with that.  Once it is functional I’ll see if I can get it work both on 4.11 (what I am using for the MPC5554) and on 4.12 (since you, Sebastian, commented it is much better).

At the end of next week I’d like to understand the plans for RTEMS releases.   Obviously 4.11 was, well, erm, a very slowly released release.   I’ve based releases on unreleased 4.11’s that go back the last five years.  If someone needs to follow up on this please start a new thread and realize I may not participate - I have a lot of work to do before next Tuesday PM.

>>>> I started everything all pthreads with the SCHED_FIFO policy (I have 
>>>> a single wrapper around pthread_create() that I use), and I’m 
>>>> guessing this field has nothing to do with that.  Some are now DFLT 
>>>> and PRIO.
>>>> I note that both WAITID and WAITQUEUE are always 0 in the DFLT case.
>>>> - Does PRIO mean the priority is boosted?  I don’t expect that, 
>>>> especially for the “muxmon” or “sokmon” threads.
>>>> - What does DFLT mean?
>>> [DFLT] means this thread doesn't wait on a thread queue
>>> [FIFO] means it waits on a thread queue in FIFO order
>>> [PRIO] means it waits on a thread queue in priority order
>>> The integer is the thread queue pointer value.
>> I started everything using SCHED_FIFO.  What’s the relationship 
>> between SCHED_FIFO, a FIFO thread queue and a PRIO thread queue?  With 
>> SCHED_FIFO I expect something to get blocked in FIFO order behind all 
>> other threads of the same priority, so I don’t understand this.
> The SCHED_FIFO scheduling policy of the threads has no impact on the 
> thread queue discipline.

What should I read to understand what the "thread queue discipline” means, so I can understand why some are PRIO and some are FIFO?

Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering.  Contact HDA to discuss methods we can use that ensure secure communication.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list