On 30/09/16 12:35, dufa...@hda.com wrote:
On Sep 30, 2016, at 01:49 , Sebastian Huber
<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?
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.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.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