On 30/09/16 22:45, dufa...@hda.com wrote:
On Sep 30, 2016, at 08:05 , Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 30/09/16 12:35, dufa...@hda.com <mailto:dufa...@hda.com> wrote:
On Sep 30, 2016, at 01:49 , Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
