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

[Sebastian Huber]

On 30/09/16 12:35, 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>> 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?

>
>> Which 4.12 version do you use
>> exactly?
>>
> This is from last weekend.  “git log .” shows the last commit to be 
> the following:
>
> commit 938ee19c5a44feade660e6872f77c548a8d89bfb
> Author: Sebastian Huber <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>>
> Date:   Fri Sep 23 10:09:57 2016 +0200
>
>     sptests/spsem03: Fix compile error
>
>
>>>
>>> I have pthreads that are showing up as DFLT and PRIO in the 
>>> “pthread” command in the shell.  For example, here:
>>>
>>> ---
>>> [/] # pthread
>>> ID         NAME       CPU PRI STATE  MODES    EVENTS WAITID   WAITQUEUE
>>> ------------------------------------------------------------------------------
>>> 0b010001                0 253 SUSP   P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b010002   grid         0 128 Wsem   P:T:nA   NONE   1a010006 
>>> 00262a78 [PRIO]
>>> 0b010003   sokmon       0  55 Wsysev P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b010004   sokmon       0 129 Wsysev P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b010005   tmsync       0 129 DELAY:Wisig P:T:nA   NONE   00000000 
>>> 00236260 [FIFO]
>>> 0b010006   log          0 129 Wsem   P:T:nA   NONE   3b010001 
>>> 00275588 [FIFO]
>>> 0b010007   fset         0 129 Wsem   P:T:nA   NONE   3b01001e 
>>> 00275a10 [FIFO]
>>> 0b010008   frm          0  25 Wsem   P:T:nA   NONE   3b010003 
>>> 002755d8 [FIFO]
>>> 0b010009   publsh       0 128 Wjatx  P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b01000a   frm          0  25 Wsem   P:T:nA   NONE   3b010007 
>>> 00275678 [FIFO]
>>> 0b01000b   publsh       0 128 Wjatx  P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b01000c   ss_srv       0 128 Wsysev P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> 0b01000d   muxmon       0 128 Wsem   P:T:nA   NONE   1a010016 
>>> 00262ef8 [PRIO]
>>> 0b01000e   commute      0   1 Wsem   P:T:nA   NONE   3b01000b 
>>> 00275718 [FIFO]
>>> 0b01000f   servo        0  17 Wsem   P:T:nA   NONE   3b010013 
>>> 00275858 [FIFO]
>>> 0b010011   tclsrv       0  55 Wsysev P:T:nA   NONE   00000000 
>>> 00000000 [DFLT]
>>> [/] #
>>> ---
>>> 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.

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