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

[Sebastian Huber]

On 30/09/16 22:45, dufault at hda.com wrote:
>
>> On Sep 30, 2016, at 08:05 , Sebastian Huber 
>> <sebastian.huber at embedded-brains.de 
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>> On 30/09/16 12:35, dufault at hda.com <mailto:dufault at hda.com> wrote:
>>>
>>>> On Sep 30, 2016, at 01:49 , Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de 
>>>> <mailto:sebastian.huber at embedded-brains.de>
>>>> <mailto:sebastian.huber at embedded-brains.de>> 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.

Ok, it seems that the AltiVec unit was used at least since RTEMS 4.10.

>
> 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).

Yes, RTEMS 4.12 should be more efficient in some important areas, e.g. 
uncontested mutex obtain/release. However, something may have regressed 
seriously.

The workspace allocations are now protected by a mutex instead of 
disable thread dispatching (changed 2014).

https://devel.rtems.org/ticket/2152

Do you use dynamic memory or create/delete RTEMS objects (e.g. threads, 
mutexes, message queues) in your high priority threads? Who creates your 
"publsh" threads?

>
> 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?

The thread queue discipline defines how threads are enqueued on a thread 
queue, e.g. in FIFO or priority order.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.