Clarify DFLT and PRIO "wait_operation" field in rtems_monitor_task_dump() in pthreads in 4.12
sebastian.huber at embedded-brains.de
Tue Oct 4 05:55:08 UTC 2016
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
The workspace allocations are now protected by a mutex instead of
disable thread dispatching (changed 2014).
Do you use dynamic memory or create/delete RTEMS objects (e.g. threads,
mutexes, message queues) in your high priority threads? Who creates your
> 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.
More information about the devel