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

[dufault at hda.com]

> On Sep 30, 2016, at 01:49 , Sebastian Huber <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.

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

Peter
-----------------
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: <http://lists.rtems.org/pipermail/devel/attachments/20160930/eca3fb96/attachment-0002.html>