Re: [Xenomai-core] measuring tasks execution time

2007-07-16 Thread Daniel Simon 
On Thu, 12 Jul 2007 13:02:35 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

Hi Jan,

  -I am thinking about more demanding tests, with intertasks preemption and
  overloads,

I have shaked my examples in various ways, with
preemptions, overruns and high load on the machine, and the exectime patch
behaves well, providing data consistent with the expectations (and with
the rt_timer_read() probe when usable).

Daniel

-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-07-12 Thread Daniel Simon 
On Wed, 11 Jul 2007 23:20:47 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

 I've merge you changes (whitespaces...)
sorry for bad formatting, my dev. tool is emacs, which sometimes refuse to
understand tabs...

http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/enhance-thread-stats-v2.patch

this patch seems ok:
-patched against release 2764 (with 2 self-corrected hunks), compiled on a
2.6.20 kernel and test on a P3/UP

 -my former basic tests (2 periodic tasks providing remote or self
exectime probing) still give consistent measures (exectime.c in attachment)

-I am thinking about more demanding tests, with intertasks preemption and
overloads, but in that case the problem is how to assess the measurements?
Logic analyzer? Be care also with rt_timer_spin, which is not busy-sleeping for
all the specified time when it is preempted...

Daniel
-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/


#include stdio.h
#include unistd.h
#include stdlib.h
#include string.h
#include strings.h
#include signal.h
#include math.h
#include sys/time.h
#include sys/io.h
#include sys/mman.h
#include native/types.h
#include native/task.h
#include native/queue.h
#include native/intr.h
#include native/timer.h
#include native/sem.h
#include native/alarm.h
#include native/heap.h
#include native/queue.h
#include native/syscall.h
#define STACK_SIZE 8192
#define MIN_PRIO 1
#define MAX_PRIO 99
#define PRI_MT_MAX MAX_PRIO - 6
#define PRI_MT_MIN MIN_PRIO

typedef void * (*FUNCPTR) (void *);
typedef void (*SOSO) (void *); /** Special type to be used for casting in task_create() */
#define ORCMSGQ RT_QUEUE *  /** Message Queue Type */
#define ORCSEM_ID RT_SEM *  /** Semaphore Type */
#define ORCFULL  1/** State of a Full Binary Semaphore */
#define ORCEMPTY 0/** State of a Empty Binary Semaphore */
#define ORCFOREVER TM_INFINITE /** Waiting forever in sem_wait */
#define SIZE_QUEUE  100   /** Size of the Message Queue */
#define SIZE_MES_MAX 4056/** Maximum size of a message in Message Queue */
#define SIZE_MES_MIN 128 /** Minimum size of a message in Message Queue */
/*---Tasks--*/
#define ORCTHR_ID RT_TASK * /** Xeno RT-Task Type */
#define STACKSIZE int  /** Stack size Type */
#define SMALL_STACK  1000   /** Small task stack size PTHREAD_STACK_MIN not defined */
#define NORMAL_STACK (5*SMALL_STACK)  /** Normal task stack size */
#define BIG_STACK(15*SMALL_STACK) /** Big task stack size */
// --s-ms-us-ns
RTIME task_period_ns = 5llu;
#define NSEC_PER_SEC 10

#define OK 0
#define ERROR -1
#define STATUS int

#define FALSE 0
#define TRUE 1
#define POLICY 1

static int ji = 0;
static RTIME startime, now;
struct timespec clock_resolution;
static int message_counter = 0;

RT_ALARM BaseClk;
int status, err, end = 0, loops = 10;

char *dummy;

ORCTHR_ID thr_clockit;
ORCTHR_ID thr_loop;
ORCMSGQ Queue;

ORCSEM_ID SynchroSem;

static int cpt_sem = 1;
char nameSem[10];
int crexec, cr;
long past = 0;
ORCTHR_ID MAIN_RT;

ORCMSGQ orcMsgQCreate()
{
size_t size;
ORCMSGQ OrcQueue;
message_counter = 0;
size = SIZE_MES_MAX;
int err;

OrcQueue = malloc(sizeof(RT_QUEUE));
if (OrcQueue == 0) {
printf(ERROR  orcMsgQCreate malloc\n);
return 0;
}
memset(OrcQueue, 0, sizeof(RT_QUEUE));
if ((err = rt_queue_create(OrcQueue, OrcRTQ, SIZE_MES_MAX*SIZE_QUEUE, SIZE_QUEUE, Q_FIFO | Q_SHARED)) != 0) {
printf(orcMsgQCreate ERROR %d \n, err);
} else printf(orcMsgQCreate OK\n);
return OrcQueue;
}

int orcMsgQSend(ORCMSGQ OrcQueue, int msg, int prio)
{
int i;
void * tmpbuf;
size_t orcEventSize;
orcEventSize = (size_t)sizeof(int);
if ((tmpbuf = rt_queue_alloc(OrcQueue, orcEventSize)) == 0) {
printf(ERROR orcMsgQSend tmpbuf not created \n);
return ERROR;
}
memcpy(tmpbuf, msg, orcEventSize);
if ((i = rt_queue_send(OrcQueue, tmpbuf, orcEventSize, Q_NORMAL))  0) {
printf(ERROR orcMsgQSend %d \n, i);
return ERROR;
}
message_counter++;
return OK;
}

int orcMsgQReceive(ORCMSGQ OrcQueue, int *msg)
{
ssize_t i;
void *message;

if ((i = rt_queue_receive(OrcQueue, message, TM_INFINITE ))  0) {
printf(ERREUR orcMsgQReceive %d \n, i);
return ERROR;
} else {
memcpy(msg, message, i);
rt_queue_free(OrcQueue, message);
message_counter--;
return OK;
}
}

int orcMsgQClose(ORCMSGQ OrcQueue)
{
int i;
if (OrcQueue == 0)

Re: [Xenomai-core] measuring tasks execution time

2007-07-12 Thread Jan Kiszka 
Daniel Simon wrote:
 On Wed, 11 Jul 2007 23:20:47 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 I've merge you changes (whitespaces...)
 sorry for bad formatting, my dev. tool is emacs, which sometimes refuse to
 understand tabs...
 
 http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/enhance-thread-stats-v2.patch
 
 this patch seems ok:
 -patched against release 2764 (with 2 self-corrected hunks), compiled on a
 2.6.20 kernel and test on a P3/UP
 
  -my former basic tests (2 periodic tasks providing remote or self
 exectime probing) still give consistent measures (exectime.c in attachment)

Nice to hear.

 
 -I am thinking about more demanding tests, with intertasks preemption and
 overloads, but in that case the problem is how to assess the measurements?
 Logic analyzer? Be care also with rt_timer_spin, which is not busy-sleeping 
 for
 all the specified time when it is preempted...

You could play with the I-pipe tracer
(http://xenomai.org/index.php/I-pipe:Tracer). If you disable function
tracing (CONFIG_IPIPE_TRACE_MCOUNT), you will be left with far less
overwhelming data, specifically with the instrumentation points on every
Xenomai context switch. That should allow some estimation of the thread
execution times (minus noise due to the IRQs). And then there is highly
experimental LTTng, but it's... well, highly experimental.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-07-11 Thread Daniel Simon 
On Sun, 08 Jul 2007 12:11:56 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

Hello,
 You are welcome to test, fix, improve, or just use it. Looking forward
 to your feedback!

here are attached some corrections against your previous patch (itself against
#2758 files): from my tests I now get likely exectime values from both remote
and self measurement (i.e. we get the accumulated exectime at the instant we
call rt_task_inquire ), and the stats given in /proc still seem to behave
normally...

the full patch against the original 2758 version is also given in attachement

Looking forward to your feedback...

Daniel
-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/


diff -urN xenomai-2758/include/nucleus/stat.h xenomai-2758-V2/include/nucleus/stat.h
--- xenomai-2758/include/nucleus/stat.h	2007-07-11 15:16:14.0 +0200
+++ xenomai-2758-V2/include/nucleus/stat.h	2007-07-11 15:09:38.0 +0200
@@ -42,7 +42,7 @@
 do { \
 	(sched)-current_account-total += \
 		date - (sched)-last_account_switch; \
-	(sched)-last_account_switch = date; \
+	(sched)-last_account_switch = (sched)-current_account-start = date; \
 	/* All changes must be committed before changing the current_account \
 	   reference in sched (required for xnintr_sync_stat_references) */ \
 	xnarch_memory_barrier(); \
@@ -71,6 +71,9 @@
 #define xnstat_runtime_get_start(account)	((account)-start)
 #define xnstat_runtime_get_total(account)	((account)-total)
 
+/* Obtain last time something has been switched */
+#define xnstat_runtime_get_last_switch(sched)	((sched)-last_account_switch)
+
 /* Reset statistics from inside the accounted entity (e.g. after CPU
migration). */
 #define xnstat_runtime_reset_stats(stat) \
@@ -113,6 +116,7 @@
 #define xnstat_runtime_finalize(sched, new_account)		do { } while (0)
 #define xnstat_runtime_get_start(account)			({ 0; })
 #define xnstat_runtime_get_total(account)			({ 0; })
+#define xnstat_runtime_get_last_switch(sched)			({ 0; })
 #define xnstat_runtime_reset_stats(account)			do { } while (0)
 
 typedef struct xnstat_counter {
diff -urN xenomai-2758/include/nucleus/thread.h xenomai-2758-V2/include/nucleus/thread.h
--- xenomai-2758/include/nucleus/thread.h	2007-07-11 15:16:14.0 +0200
+++ xenomai-2758-V2/include/nucleus/thread.h	2007-07-11 14:28:15.0 +0200
@@ -294,7 +294,7 @@
 #define xnthread_affinity(thread)  ((thread)-affinity)
 #define xnthread_affine_p(thread, cpu) xnarch_cpu_isset(cpu, (thread)-affinity)
 #define xnthread_get_exectime(thread)  xnstat_runtime_get_total((thread)-stat.account)
-#define xnthread_get_lastswitch(thread)xnstat_runtime_get_start((thread)-stat.account)
+#define xnthread_get_lastswitch(thread)xnstat_runtime_get_last_switch((thread)-sched)
 
 /* Class-level operations for threads. */
 static inline int xnthread_get_denormalized_prio(xnthread_t *t)
diff -urN xenomai-2758/ksrc/skins/native/task.c xenomai-2758-V2/ksrc/skins/native/task.c
--- xenomai-2758/ksrc/skins/native/task.c	2007-07-11 15:16:14.0 +0200
+++ xenomai-2758-V2/ksrc/skins/native/task.c	2007-07-11 15:22:10.0 +0200
@@ -1144,10 +1144,13 @@
 	info-cprio = xnthread_current_priority(task-thread_base);
 	info-status = xnthread_state_flags(task-thread_base);
 	info-relpoint = xntimer_get_date(task-thread_base.ptimer);
+	if(task == xeno_current_task())
 	info-exectime = xnarch_tsc_to_ns(
 		xnthread_get_exectime(task-thread_base) +
 		xnstat_runtime_now() -
 		xnthread_get_lastswitch(task-thread_base));
+	else 
+	  info-exectime = xnarch_tsc_to_ns(xnthread_get_exectime(task-thread_base));
 	info-modeswitches = xnstat_counter_get(task-thread_base.stat.ssw);
 	info-ctxswitches = xnstat_counter_get(task-thread_base.stat.csw);
 	info-pagefaults = xnstat_counter_get(task-thread_base.stat.pf);
diff -urN xenomai/include/native/task.h xenomai-2758-V2/include/native/task.h
--- xenomai/include/native/task.h	2007-07-09 13:06:54.0 +0200
+++ xenomai-2758-V2/include/native/task.h	2007-07-11 09:55:02.0 +0200
@@ -90,6 +90,14 @@
 
 char name[XNOBJECT_NAME_LEN];  /** Symbolic name assigned at creation. */
 
+RTIME exectime; /** Execution time in primary mode in nanoseconds. */
+
+int modeswitches; /** Number of primary-secondary mode switches. */
+
+int ctxswitches; /** Number of context switches. */
+
+int pagefaults; /** Number of triggered page faults. */
+
 } RT_TASK_INFO;
 
 #define RT_MCB_FSTORE_LIMIT  64
diff -urN xenomai/include/nucleus/stat.h xenomai-2758-V2/include/nucleus/stat.h
--- xenomai/include/nucleus/stat.h	2007-07-09 13:07:01.0 +0200
+++ xenomai-2758-V2/include/nucleus/stat.h	2007-07-11 15:09:38.0 +0200
@@ -42,7 +42,7 @@
 do { \
 	(sched)-current_account-total += \
 		date -

Re: [Xenomai-core] measuring tasks execution time

2007-07-11 Thread Jan Kiszka 
Daniel Simon wrote:
 On Sun, 08 Jul 2007 12:11:56 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 Hello,
 You are welcome to test, fix, improve, or just use it. Looking forward
 to your feedback!
 
 here are attached some corrections against your previous patch (itself against
 #2758 files): from my tests I now get likely exectime values from both remote
 and self measurement (i.e. we get the accumulated exectime at the instant we
 call rt_task_inquire ), and the stats given in /proc still seem to behave
 normally...
 
 the full patch against the original 2758 version is also given in attachement

To check if I got it the first attachment is an add-on patch, the second
one is the base patch as in my repos + the former add-on patch?

Then let's comment on the add-on:

 diff -urN xenomai-2758/include/nucleus/stat.h 
 xenomai-2758-V2/include/nucleus/stat.h
 --- xenomai-2758/include/nucleus/stat.h   2007-07-11 15:16:14.0 
 +0200
 +++ xenomai-2758-V2/include/nucleus/stat.h2007-07-11 15:09:38.0 
 +0200
 @@ -42,7 +42,7 @@
  do { \
   (sched)-current_account-total += \
   date - (sched)-last_account_switch; \
 - (sched)-last_account_switch = date; \
 + (sched)-last_account_switch = (sched)-current_account-start = date; \

That looks bogus on first sight, but I might miss your intention.
current_account points to the overall stats of an accounted entity.
Therefore, start must always contain the start time, not the last switch
time. Please explain your idea.

   /* All changes must be committed before changing the current_account \
  reference in sched (required for xnintr_sync_stat_references) */ \
   xnarch_memory_barrier(); \
 @@ -71,6 +71,9 @@
  #define xnstat_runtime_get_start(account)((account)-start)
  #define xnstat_runtime_get_total(account)((account)-total)
  
 +/* Obtain last time something has been switched */
 +#define xnstat_runtime_get_last_switch(sched)
 ((sched)-last_account_switch)
 +

OK (though a more precise comment would be good :))

  /* Reset statistics from inside the accounted entity (e.g. after CPU
 migration). */
  #define xnstat_runtime_reset_stats(stat) \
 @@ -113,6 +116,7 @@
  #define xnstat_runtime_finalize(sched, new_account)  do { } while (0)
  #define xnstat_runtime_get_start(account)({ 0; })
  #define xnstat_runtime_get_total(account)({ 0; })
 +#define xnstat_runtime_get_last_switch(sched)({ 0; })
  #define xnstat_runtime_reset_stats(account)  do { } while (0)
  
  typedef struct xnstat_counter {
 diff -urN xenomai-2758/include/nucleus/thread.h 
 xenomai-2758-V2/include/nucleus/thread.h
 --- xenomai-2758/include/nucleus/thread.h 2007-07-11 15:16:14.0 
 +0200
 +++ xenomai-2758-V2/include/nucleus/thread.h  2007-07-11 14:28:15.0 
 +0200
 @@ -294,7 +294,7 @@
  #define xnthread_affinity(thread)  ((thread)-affinity)
  #define xnthread_affine_p(thread, cpu) xnarch_cpu_isset(cpu, 
 (thread)-affinity)
  #define xnthread_get_exectime(thread)  
 xnstat_runtime_get_total((thread)-stat.account)
 -#define xnthread_get_lastswitch(thread)
 xnstat_runtime_get_start((thread)-stat.account)
 +#define xnthread_get_lastswitch(thread)
 xnstat_runtime_get_last_switch((thread)-sched)

Yeah, that was wrong. Did your first patch hunk relate to an initial
attempt to fix this bug?

  
  /* Class-level operations for threads. */
  static inline int xnthread_get_denormalized_prio(xnthread_t *t)
 diff -urN xenomai-2758/ksrc/skins/native/task.c 
 xenomai-2758-V2/ksrc/skins/native/task.c
 --- xenomai-2758/ksrc/skins/native/task.c 2007-07-11 15:16:14.0 
 +0200
 +++ xenomai-2758-V2/ksrc/skins/native/task.c  2007-07-11 15:22:10.0 
 +0200
 @@ -1144,10 +1144,13 @@
   info-cprio = xnthread_current_priority(task-thread_base);
   info-status = xnthread_state_flags(task-thread_base);
   info-relpoint = xntimer_get_date(task-thread_base.ptimer);
 + if(task == xeno_current_task())
   info-exectime = xnarch_tsc_to_ns(
   xnthread_get_exectime(task-thread_base) +
   xnstat_runtime_now() -
   xnthread_get_lastswitch(task-thread_base));
 + else 
 +   info-exectime = 
 xnarch_tsc_to_ns(xnthread_get_exectime(task-thread_base));

OK, second bug taken. But you approach was written without SMP in mind
(while I thought too much about SMP). The correct condition is task is
running, somewhere?:

if (task-thread_base.sched-runthread == task-thread_base)
exectime up to now
else
currently stored exectime

Of course, one may still optimise the expression.

   info-modeswitches = xnstat_counter_get(task-thread_base.stat.ssw);
   info-ctxswitches = xnstat_counter_get(task-thread_base.stat.csw);
   info-pagefaults = xnstat_counter_get(task-thread_base.stat.pf);
 
 

Jan



signature.asc
Description: OpenPGP digital

Re: [Xenomai-core] measuring tasks execution time

2007-07-11 Thread Daniel Simon 
On Wed, 11 Jul 2007 16:30:03 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

 Daniel Simon wrote:
  On Sun, 08 Jul 2007 12:11:56 +0200
  Jan Kiszka [EMAIL PROTECTED] wrote:
  
  Hello,
  You are welcome to test, fix, improve, or just use it. Looking forward
  to your feedback!
  
  here are attached some corrections against your previous patch (itself 
  against
  #2758 files): from my tests I now get likely exectime values from both 
  remote
  and self measurement (i.e. we get the accumulated exectime at the instant we
  call rt_task_inquire ), and the stats given in /proc still seem to behave
  normally...
  
  the full patch against the original 2758 version is also given in 
  attachement
 
 To check if I got it the first attachment is an add-on patch, the second
 one is the base patch as in my repos + the former add-on patch?
yes
 Then let's comment on the add-on:
 
  diff -urN xenomai-2758/include/nucleus/stat.h 
  xenomai-2758-V2/include/nucleus/stat.h
  --- xenomai-2758/include/nucleus/stat.h 2007-07-11 15:16:14.0 
  +0200
  +++ xenomai-2758-V2/include/nucleus/stat.h  2007-07-11 15:09:38.0 
  +0200
  @@ -42,7 +42,7 @@
   do { \
  (sched)-current_account-total += \
  date - (sched)-last_account_switch; \
  -   (sched)-last_account_switch = date; \
  +   (sched)-last_account_switch = (sched)-current_account-start = date; \
 
 That looks bogus on first sight, but I might miss your intention.
 current_account points to the overall stats of an accounted entity.
 Therefore, start must always contain the start time, not the last switch
 time. Please explain your idea.

sorry, I forgot to delete this attempt to correct a former bug, it's useless 
now, line 45 in stat.h remains as 
in your original patch

(sched)-last_account_switch = date; \

just tested, the exectime measure still works...
  /* All changes must be committed before changing the current_account \
 reference in sched (required for xnintr_sync_stat_references) */ \
  xnarch_memory_barrier(); \
  @@ -71,6 +71,9 @@
   #define xnstat_runtime_get_start(account)  ((account)-start)
   #define xnstat_runtime_get_total(account)  ((account)-total)
   
  +/* Obtain last time something has been switched */
  +#define xnstat_runtime_get_last_switch(sched)  
  ((sched)-last_account_switch)
  +
 
 OK (though a more precise comment would be good :))
 
/* Get the last time the calling thread was switched active */ 

may be better, but it could be also an intr. handler, isn't?

   /* Reset statistics from inside the accounted entity (e.g. after CPU
  migration). */
   #define xnstat_runtime_reset_stats(stat) \
  @@ -113,6 +116,7 @@
   #define xnstat_runtime_finalize(sched, new_account)do { } 
  while (0)
   #define xnstat_runtime_get_start(account)  ({ 0; })
   #define xnstat_runtime_get_total(account)  ({ 0; })
  +#define xnstat_runtime_get_last_switch(sched)  ({ 0; })
   #define xnstat_runtime_reset_stats(account)do { } 
  while (0)
   
   typedef struct xnstat_counter {
  diff -urN xenomai-2758/include/nucleus/thread.h 
  xenomai-2758-V2/include/nucleus/thread.h
  --- xenomai-2758/include/nucleus/thread.h   2007-07-11 15:16:14.0 
  +0200
  +++ xenomai-2758-V2/include/nucleus/thread.h2007-07-11 
  14:28:15.0 +0200
  @@ -294,7 +294,7 @@
   #define xnthread_affinity(thread)  ((thread)-affinity)
   #define xnthread_affine_p(thread, cpu) xnarch_cpu_isset(cpu, 
  (thread)-affinity)
   #define xnthread_get_exectime(thread)  
  xnstat_runtime_get_total((thread)-stat.account)
  -#define xnthread_get_lastswitch(thread)
  xnstat_runtime_get_start((thread)-stat.account)
  +#define xnthread_get_lastswitch(thread)
  xnstat_runtime_get_last_switch((thread)-sched)
 
 Yeah, that was wrong. Did your first patch hunk relate to an initial
 attempt to fix this bug?
 
yes, it was made to cancel an extra period in the measure
   
   /* Class-level operations for threads. */
   static inline int xnthread_get_denormalized_prio(xnthread_t *t)
  diff -urN xenomai-2758/ksrc/skins/native/task.c 
  xenomai-2758-V2/ksrc/skins/native/task.c
  --- xenomai-2758/ksrc/skins/native/task.c   2007-07-11 15:16:14.0 
  +0200
  +++ xenomai-2758-V2/ksrc/skins/native/task.c2007-07-11 
  15:22:10.0 +0200
  @@ -1144,10 +1144,13 @@
  info-cprio = xnthread_current_priority(task-thread_base);
  info-status = xnthread_state_flags(task-thread_base);
  info-relpoint = xntimer_get_date(task-thread_base.ptimer);
  +   if(task == xeno_current_task())
  info-exectime = xnarch_tsc_to_ns(
  xnthread_get_exectime(task-thread_base) +
  xnstat_runtime_now() -
  xnthread_get_lastswitch(task-thread_base));
  +   else 
  + info-exectime = 
  xnarch_tsc_to_ns(xnthread_get_exectime(task-thread_base));
 
 OK, second bug taken. But you

Re: [Xenomai-core] measuring tasks execution time

2007-07-11 Thread Daniel Simon 
On Wed, 11 Jul 2007 17:56:09 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

 Let's find a compromise: I will try to role out -v2 of this patch with
 your fixes soon. And you will try to do the in-depth tests of exectime
 reporting once you have a Xenomai box again? Hacking is cheap, testing
 takes the time... :) Or does the test code you once submitted report
 clear results /wrt the correctness of the exectime data?

What I mean is that I can perform tests _only on a Pentium3 UP_, and on this
machine I upto now get consistent results on the basic tests using the last
fixes (and I will do further testing with various applications).

I cannot (and will not be able in a previsible future) perform tests
neither on a SMP nor on not_i386 architectures...

In attachment: 
the full exectime-V2.patch (including all the fixes we discussed
today) against a vanilla 2758 release, which compiled and behaves well on my
basic examples and UP machine. (it also patches with no hunk against
last release 2764), 
and the add-on against your original patch (I don't know what
is the easiest way for you...)

Daniel

-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/


diff -urN xenomai/include/native/task.h xenomai-2758-V2/include/native/task.h
--- xenomai/include/native/task.h	2007-07-09 13:06:54.0 +0200
+++ xenomai-2758-V2/include/native/task.h	2007-07-11 09:55:02.0 +0200
@@ -90,6 +90,14 @@
 
 char name[XNOBJECT_NAME_LEN];  /** Symbolic name assigned at creation. */
 
+RTIME exectime; /** Execution time in primary mode in nanoseconds. */
+
+int modeswitches; /** Number of primary-secondary mode switches. */
+
+int ctxswitches; /** Number of context switches. */
+
+int pagefaults; /** Number of triggered page faults. */
+
 } RT_TASK_INFO;
 
 #define RT_MCB_FSTORE_LIMIT  64
diff -urN xenomai/include/nucleus/stat.h xenomai-2758-V2/include/nucleus/stat.h
--- xenomai/include/nucleus/stat.h	2007-07-09 13:07:01.0 +0200
+++ xenomai-2758-V2/include/nucleus/stat.h	2007-07-11 15:09:38.0 +0200
@@ -42,7 +42,7 @@
 do { \
 	(sched)-current_account-total += \
 		date - (sched)-last_account_switch; \
-	(sched)-last_account_switch = date; \
+	(sched)-last_account_switch = (sched)-current_account-start = date; \
 	/* All changes must be committed before changing the current_account \
 	   reference in sched (required for xnintr_sync_stat_references) */ \
 	xnarch_memory_barrier(); \
@@ -67,6 +67,13 @@
 	(sched)-current_account = (new_account); \
 } while (0)
 
+/* Obtain content of xnstat_runtime_t */
+#define xnstat_runtime_get_start(account)	((account)-start)
+#define xnstat_runtime_get_total(account)	((account)-total)
+
+/* Obtain last time something has been switched */
+#define xnstat_runtime_get_last_switch(sched)	((sched)-last_account_switch)
+
 /* Reset statistics from inside the accounted entity (e.g. after CPU
migration). */
 #define xnstat_runtime_reset_stats(stat) \
@@ -104,9 +111,12 @@
 
 #define xnstat_runtime_now()	({ 0; })
 #define xnstat_runtime_update(sched, date)			do { } while (0)
-#define xnstat_runtime_set_current(sched, new_account)	({ (void)sched; NULL; })
+#define xnstat_runtime_set_current(sched, new_account)		({ (void)sched; NULL; })
 #define xnstat_runtime_get_current(sched)			({ (void)sched; NULL; })
 #define xnstat_runtime_finalize(sched, new_account)		do { } while (0)
+#define xnstat_runtime_get_start(account)			({ 0; })
+#define xnstat_runtime_get_total(account)			({ 0; })
+#define xnstat_runtime_get_last_switch(sched)			({ 0; })
 #define xnstat_runtime_reset_stats(account)			do { } while (0)
 
 typedef struct xnstat_counter {
diff -urN xenomai/include/nucleus/thread.h xenomai-2758-V2/include/nucleus/thread.h
--- xenomai/include/nucleus/thread.h	2007-07-09 13:07:01.0 +0200
+++ xenomai-2758-V2/include/nucleus/thread.h	2007-07-11 14:28:15.0 +0200
@@ -205,7 +205,8 @@
 	xnstat_counter_t ssw;	/* Primary - secondary mode switch count */
 	xnstat_counter_t csw;	/* Context switches (includes secondary - primary switches) */
 	xnstat_counter_t pf;	/* Number of page faults */
-	xnstat_runtime_t account; /* Runtime accounting entity */
+	xnstat_runtime_t account; /* Execution time accounting entity */
+	xnstat_runtime_t lastperiod; /* Interval marker for execution time reports */
 } stat;
 
 int errcode;		/* Local errno */
@@ -235,8 +236,6 @@
 
 char name[XNOBJECT_NAME_LEN]; /* Symbolic name of thread */
 
-xnticks_t stime;		/* Start time */
-
 void (*entry)(void *cookie); /* Thread entry routine */
 
 void *cookie;		/* Cookie to pass to the entry routine */
@@ -294,6 +293,8 @@
 0 : xnarch_user_pid(xnthread_archtcb(thread)))
 #define xnthread_affinity(thread)  ((thread)-affinity)
 #define

Re: [Xenomai-core] measuring tasks execution time

2007-07-11 Thread Jan Kiszka 
Daniel Simon wrote:
 On Wed, 11 Jul 2007 17:56:09 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 Let's find a compromise: I will try to role out -v2 of this patch with
 your fixes soon. And you will try to do the in-depth tests of exectime
 reporting once you have a Xenomai box again? Hacking is cheap, testing
 takes the time... :) Or does the test code you once submitted report
 clear results /wrt the correctness of the exectime data?
 
 What I mean is that I can perform tests _only on a Pentium3 UP_, and on this
 machine I upto now get consistent results on the basic tests using the last
 fixes (and I will do further testing with various applications).

Ah, ok, /me should have read more thoroughly.

 
 I cannot (and will not be able in a previsible future) perform tests
 neither on a SMP nor on not_i386 architectures...
 
 In attachment: 
 the full exectime-V2.patch (including all the fixes we discussed
 today) against a vanilla 2758 release, which compiled and behaves well on my
 basic examples and UP machine. (it also patches with no hunk against
 last release 2764), 
 and the add-on against your original patch (I don't know what
 is the easiest way for you...)
 

I've merge you changes (whitespaces...), reformatted it a bit, and
uploaded the result. See

http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/enhance-thread-stats-v2.patch

Hope I didn't messed anything up, it was just compile-tested in a hurry.
If the patch happens to work fine, I would start advertising it for
merge into trunk.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-07-09 Thread Daniel Simon 
On Sun, 08 Jul 2007 12:11:56 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

 You are welcome to test, fix, improve, or just use it. Looking forward
 to your feedback!

Thanks, I'll try it this week

Daniel
-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-07-08 Thread Jan Kiszka 
Daniel Simon wrote:
 please find attached a new patch following these ideas:
  (patch against svn trunk Revision: 2672) 
 

Based on this version, I integrated your patch into my patch stack. The
actual rt_task_inquire interface is totally untested, but the rest
appears to cause no regressions here. See

http://www.rts.uni-hannover.de/rtaddon/patches/xenomai

namely the enhance-thread-stats.patch. It may depend on some of the
previous patches in the stack, but only organisationally, not technically.

You are welcome to test, fix, improve, or just use it. Looking forward
to your feedback!

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-29 Thread Jan Kiszka 
Daniel Simon wrote:
 On Wed, 27 Jun 2007 13:56:04 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 On Mon, 25 Jun 2007 18:55:45 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 My idea was to keep a persistent version the existing xnstat_runtime_t
 instance in xnthread (and later on also xnintr). That one shall not be
 reset on readout via /proc.
 Is it necessary to keep also the reset one?
 Yep, at least virtually (as in my proposal): We are dumping CPU share
 percentages in /proc, and those need to be calculated over the same
 measurement period. Thus we restart the measurement each time the user
 reads the stats.

 Let's try it like this: Change Xenomai so that it leaves the existing
 xnthread_t::stat.account untouched when it reads /proc. Rather add
 something like  last; to xnthread_t::stat. On readout
 for /proc output, 
 
 That's one spot, the other is xnpod_migrate_thread()
 (xnstat_runtime_reset_stats()) IIRC.
 
 ok, i've found only these two reset points.
 
 the account structure is also partially touched by  xnstat_runtime_finalize()
 in pod.c, I don't understand when and why...

xnstat_runtime_finalize is called when a task passes away, i.e. you
wouldn't be able to retrieve it's stats later on anyway.

 
 account into last. For your task exectime, you can then read
 xnthread_t::stat.account directly, because it will always reflect the
 full task history. Would't this work better?
 Jan

 please find attached a new patch following these ideas:
  (patch against svn trunk Revision: 2672) 
 
 account is now persistent, its start field is the last_switch time, and the
 new xnstat_runtime_t lastperiod handles the past values necessary to compute
 the runtime values plot at snapshot time.
 
 from a few trials, it seems that /proc/xenomai/stat still behaves normally 
 (i.e.
 like in the original version where the first reading of stat does gives 
 nothing
 for the tasks runtime?)

The first dump is always bogus as the task set changed since the
previous measurement date (here: Xenomai start-up time).

 
 exectime returns likely values when a task is measured by another one, but 
 self
 measurement (with the NULL task calling parameter in rt_task_inquire) sometime
 provides incoherent values (e.g. returns the period rather than the exectime,
 or returns non-monotonic exectime values...). 
 I could not manage to fix this bug upto now. 

I think I already see one, though it doesn't explain all your observed
behaviour to me:

 --- xenomai-orig/ksrc/skins/native/task.c 2007-06-28 10:20:17.0 
 +0200
 +++ xenomai/ksrc/skins/native/task.c  2007-06-28 17:20:29.0 +0200
 @@ -1144,7 +1144,10 @@
   info-cprio = xnthread_current_priority(task-thread_base);
   info-status = xnthread_state_flags(task-thread_base);
   info-relpoint = xntimer_get_date(task-thread_base.ptimer);
 -
 + if(task == xeno_current_task())
 +   info-exectime = xnthread_get_exectime(task-thread_base) + 
 (xnstat_runtime_now() - xnthread_get_lastswitch(task-thread_base));
 + else 
 +   info-exectime = xnthread_get_exectime(task-thread_base);

Exectime is only updated on task switches. So you are not obtaining the true 
value when requesting your own data. Use the same formula for both cases.

 And unfortunately i'll be away and probably far from any xenomai-capable
 machine next week...
 

OK. I'll try to look into this in the meantime. But I think it should be no 
problem to merge a final version even after the approaching 2.4-rc1, the patch 
is yet fairly confined.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-29 Thread Jan Kiszka 
Daniel Simon wrote:
 On Fri, 29 Jun 2007 17:00:39 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 Exectime is only updated on task switches. So you are not obtaining the true
 value when requesting your own data. Use the same formula for both cases.
 
 yes, but like that the fraction of time spent in the current execution is not
 accounted, which might be sometimes useful (e.g. to integrate the cost of a
 feedback scheduler in the total control budget)

Yeah, true, I applied the inverse logic. However, this interface is
inconsistent, one should expects the same algorithm applied on both
local as well as remote task queries. Why do you differentiate?

 
 another potentially useful feature would be also accounting the execution time
 spent in secondary mode... no idea on how to do that. 
 BTW, Posix defines an optional CLOCK_THREAD_CPUTIME which is assumed to 
 provide
 this measure ?

This should work for shadow threads to retrieve their secondary-mode
runtime. Give it a try.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-29 Thread Daniel Simon 
On Fri, 29 Jun 2007 17:00:39 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

 Exectime is only updated on task switches. So you are not obtaining the true
 value when requesting your own data. Use the same formula for both cases.

yes, but like that the fraction of time spent in the current execution is not
accounted, which might be sometimes useful (e.g. to integrate the cost of a
feedback scheduler in the total control budget)

another potentially useful feature would be also accounting the execution time
spent in secondary mode... no idea on how to do that. 
BTW, Posix defines an optional CLOCK_THREAD_CPUTIME which is assumed to provide
this measure ?

Daniel

-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-29 Thread Philippe Gerum 
On Fri, 2007-06-29 at 17:29 +0200, Daniel Simon wrote:
 On Fri, 29 Jun 2007 17:00:39 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
  Exectime is only updated on task switches. So you are not obtaining the true
  value when requesting your own data. Use the same formula for both cases.
 
 yes, but like that the fraction of time spent in the current execution is not
 accounted, which might be sometimes useful (e.g. to integrate the cost of a
 feedback scheduler in the total control budget)
 
 another potentially useful feature would be also accounting the execution time
 spent in secondary mode... no idea on how to do that. 

Xenomai-wise, secondary mode starts for an emerging thread in
xnshadow_map(), then stops when exiting xnshadow_harden(), then resumes
when exiting xnshadow_relax(). All routines are defined in
nucleus/shadow.c.

 BTW, Posix defines an optional CLOCK_THREAD_CPUTIME which is assumed to 
 provide
 this measure ?
 
   Daniel
 
-- 
Philippe.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-29 Thread Gilles Chanteperdrix 
On 6/29/07, Philippe Gerum [EMAIL PROTECTED] wrote:
 On Fri, 2007-06-29 at 17:29 +0200, Daniel Simon wrote:
  On Fri, 29 Jun 2007 17:00:39 +0200
  Jan Kiszka [EMAIL PROTECTED] wrote:
 
   Exectime is only updated on task switches. So you are not obtaining the 
   true
   value when requesting your own data. Use the same formula for both cases.
 
  yes, but like that the fraction of time spent in the current execution is 
  not
  accounted, which might be sometimes useful (e.g. to integrate the cost of a
  feedback scheduler in the total control budget)
 
  another potentially useful feature would be also accounting the execution 
  time
  spent in secondary mode... no idea on how to do that.

 Xenomai-wise, secondary mode starts for an emerging thread in
 xnshadow_map(), then stops when exiting xnshadow_harden(), then resumes
 when exiting xnshadow_relax(). All routines are defined in
 nucleus/shadow.c.

Additionnaly when a task is suspended by Linux, the function
do_schedule_event is triggered by Adeos.

-- 
   Gilles Chanteperdrix

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-27 Thread Daniel Simon 
On Mon, 25 Jun 2007 18:55:45 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:



 My idea was to keep a persistent version the existing xnstat_runtime_t
 instance in xnthread (and later on also xnintr). That one shall not be
 reset on readout via /proc.
Is it necessary to keep also the reset one?

 Instead, you establish quite some new calculations that break
 the existing API (the switch date is given via start - which was
 misnamed so far, I just changed it to date) 

ok, better fit the behaviour.
I should better work from the last svn version?

and increase the runtime
 overhead in the hotpath. Why? All the information you should need is
 already there, it just has to be saved from being vaporised when the
 user dumps /proc/xenomai/stat.
 
  (sched)-last_account_switch = start; \
   } while (0)
 
 
 Let's try it like this: Change Xenomai so that it leaves the existing
 xnthread_t::stat.account untouched when it reads /proc. Rather add
 something like xnstat_runtime_t last; to xnthread_t::stat. On readout
 for /proc output, 
Where is this done? I've found one place in module::stat_seq_open where total is
reset to 0, is it the only one? 
In fact I don't have a clear picture of the stat
process and what it is assumed to do (and thus did not want to break something!)
do the stats now like account-last and then move
 account into last. For your task exectime, you can then read
 xnthread_t::stat.account directly, because it will always reflect the
 full task history. Would't this work better?

 Thanks for working on this!
I'll try to find enough time by the end of this week to improve this...

Daniel

-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-27 Thread Jan Kiszka 
Daniel Simon wrote:
 On Mon, 25 Jun 2007 18:55:45 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 
 
 My idea was to keep a persistent version the existing xnstat_runtime_t
 instance in xnthread (and later on also xnintr). That one shall not be
 reset on readout via /proc.
 Is it necessary to keep also the reset one?

Yep, at least virtually (as in my proposal): We are dumping CPU share
percentages in /proc, and those need to be calculated over the same
measurement period. Thus we restart the measurement each time the user
reads the stats.

 
 Instead, you establish quite some new calculations that break
 the existing API (the switch date is given via start - which was
 misnamed so far, I just changed it to date) 
 
 ok, better fit the behaviour.
 I should better work from the last svn version?

SVN trunk would be best, indeed.

 
 and increase the runtime
 overhead in the hotpath. Why? All the information you should need is
 already there, it just has to be saved from being vaporised when the
 user dumps /proc/xenomai/stat.

 (sched)-last_account_switch = start; \
  } while (0)

 Let's try it like this: Change Xenomai so that it leaves the existing
 xnthread_t::stat.account untouched when it reads /proc. Rather add
 something like xnstat_runtime_t last; to xnthread_t::stat. On readout
 for /proc output, 
 Where is this done? I've found one place in module::stat_seq_open where total 
 is
 reset to 0, is it the only one? 

That's one spot, the other is xnpod_migrate_thread()
(xnstat_runtime_reset_stats()) IIRC.

 In fact I don't have a clear picture of the stat
 process and what it is assumed to do (and thus did not want to break 
 something!)

Stat generation happens based on services that are provided by
nucleus/stat.h, stat dumping is concentrated in modules.c, namely
stat_seq_open. Using the cross reference [1] can help if you want to
verify this on your own.

 do the stats now like account-last and then move
 account into last. For your task exectime, you can then read
 xnthread_t::stat.account directly, because it will always reflect the
 full task history. Would't this work better?
 
 Thanks for working on this!
 I'll try to find enough time by the end of this week to improve this...
 
   Daniel
 

Looking forward.

Jan

[1] http://www.rts.uni-hannover.de/xenomai/lxr/source/?v=SVN-trunk



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] measuring tasks execution time

2007-06-25 Thread Daniel Simon 
On Fri, 08 Jun 2007 13:20:11 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:

Hello,

 Well, the best (==most comfortable :o) ) way from my POV would be if you
 could try rebasing your work on your own first. Questions, even on minor
 details, are always welcome, review on patches will be provided. Should
 be no problem to get this into Xenomai 2.4.
 
 The rough to-do list would be:
 
  o add some persistent runtimer counter to xnthread::stat and maintain
it
  o introduce an xnpod service (inline function) to obtain it (let that
thing return [0..LONGLONG_MAX] when stats are available, -1
otherwise)
  o export the runtime via struct rt_task_info, maybe also the task start
time

Coming back on this topic:
please find attached a first draft of a patch following (more or less)  your
suggestions:
-there is an additional field exectime in  TASK_INFO, which can be set by
rt_task_inquire and read in the info structure (the computation is slightly
different for self and remote measurement);
-xnthread_get_exectime() and xnthread_get_lastswitch() pass the values of the
current thread's  timing out of xn;
-exectime and lastswitch times are stored in an extended xnstat_runtime_t,
updated by xnstat_runtime_update() (but not exactly like the total item)

it has been tested (only on  P3 single core cpu) with the testexec program also
attached : there are 2 periodic tasks, clockit and loop, which measure
either their exectime, or the one of the other task: the measures 
seems reasonable, except when the clockit task measures itself, in that case the
first and second printed values are always absurd for a reason I cannot
understand...)

Only works in primary mode... (also I hope that the tsc is monotonic?)

I have no idea of what may happen on a smp or when on the fly migrating tasks!

Daniel

-- 
   Daniel SIMONProjet NeCS  INRIA Rhone-Alpes
Inovallee, 655 avenue de l'Europe, Montbonnot
 38 334 Saint Ismier Cedex France
 [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252
  http://necs.inrialpes.fr/people/simon/


diff -urN xenomai-2.3.1-orig/include/native/task.h xenomai-2.3.1/include/native/task.h
--- xenomai-2.3.1-orig/include/native/task.h	2006-12-26 19:38:57.0 +0100
+++ xenomai-2.3.1/include/native/task.h	2007-06-22 16:08:10.0 +0200
@@ -91,6 +91,8 @@
 
 char name[XNOBJECT_NAME_LEN];  /** Symbolic name assigned at creation. */
 
+xnticks_t exectime; /**execution time in tsc ticks since the task started. */
+
 } RT_TASK_INFO;
 
 #define RT_MCB_FSTORE_LIMIT  64
diff -urN xenomai-2.3.1-orig/include/nucleus/stat.h xenomai-2.3.1/include/nucleus/stat.h
--- xenomai-2.3.1-orig/include/nucleus/stat.h	2006-12-26 19:38:59.0 +0100
+++ xenomai-2.3.1/include/nucleus/stat.h	2007-06-25 15:48:25.0 +0200
@@ -31,6 +31,10 @@
 
 	xnticks_t total; /* Accumulated execution time */
 
+	xnticks_t exectime; /* Overall execution time from taskspawn upto lastswitch*/
+
+	xnticks_t lastswitch; /* Last time the task was made active */
+
 } xnstat_runtime_t;
 
 /* Return current date which can be passed to other xnstat services for
@@ -42,6 +46,10 @@
 do { \
 	(sched)-current_account-total += \
 		start - (sched)-last_account_switch; \
+	(sched)-current_account-exectime += \
+xnstat_runtime_now() - (sched)-last_account_switch; \
+	(sched)-current_account-lastswitch = \
+xnstat_runtime_now(); \
 	(sched)-last_account_switch = start; \
 } while (0)
 
diff -urN xenomai-2.3.1-orig/include/nucleus/thread.h xenomai-2.3.1/include/nucleus/thread.h
--- xenomai-2.3.1-orig/include/nucleus/thread.h	2007-03-15 15:10:30.0 +0100
+++ xenomai-2.3.1/include/nucleus/thread.h	2007-06-22 16:17:24.0 +0200
@@ -228,6 +228,7 @@
 
 void *cookie;		/* Cookie to pass to the entry routine */
 
+
 XNARCH_DECL_DISPLAY_CONTEXT();
 
 } xnthread_t;
@@ -277,7 +278,8 @@
 #define xnthread_user_pid(thread) \
 (xnthread_test_state((thread),XNROOT) || !xnthread_user_task(thread) ? \
 0 : xnarch_user_pid(xnthread_archtcb(thread)))
-
+#define xnthread_get_exectime(thread)  ((thread)-stat.account.exectime)
+#define xnthread_get_lastswitch(thread)((thread)-stat.account.lastswitch)
 #ifdef __cplusplus
 extern C {
 #endif
diff -urN xenomai-2.3.1-orig/ksrc/nucleus/thread.c xenomai-2.3.1/ksrc/nucleus/thread.c
--- xenomai-2.3.1-orig/ksrc/nucleus/thread.c	2007-02-02 02:17:32.0 +0100
+++ xenomai-2.3.1/ksrc/nucleus/thread.c	2007-06-22 16:55:08.0 +0200
@@ -89,7 +89,10 @@
 	thread-registry.waitkey = NULL;
 #endif /* CONFIG_XENO_OPT_REGISTRY */
 	memset(thread-stat, 0, sizeof(thread-stat));
-
+#ifdef CONFIG_XENO_OPT_STATS
+	thread-stat.account.exectime = 0;
+	thread-stat.account.lastswitch = 0;
+#endif
 	/* These will be filled by xnpod_start_thread() */
 	thread-imask = 0;
 	thread-imode = 0;
diff -urN xenomai-2.3.1-orig/ksrc/skins/native/task.c xenomai-2.3.1/ksrc/skins/native/task.c
---

Re: [Xenomai-core] measuring tasks execution time

2007-06-25 Thread Jan Kiszka 
Daniel Simon wrote:
 On Fri, 08 Jun 2007 13:20:11 +0200
 Jan Kiszka [EMAIL PROTECTED] wrote:
 
 Hello,
 
 Well, the best (==most comfortable :o) ) way from my POV would be if you
 could try rebasing your work on your own first. Questions, even on minor
 details, are always welcome, review on patches will be provided. Should
 be no problem to get this into Xenomai 2.4.

 The rough to-do list would be:

  o add some persistent runtimer counter to xnthread::stat and maintain
it
  o introduce an xnpod service (inline function) to obtain it (let that
thing return [0..LONGLONG_MAX] when stats are available, -1
otherwise)
  o export the runtime via struct rt_task_info, maybe also the task start
time
 
 Coming back on this topic:
 please find attached a first draft of a patch following (more or less)  your
 suggestions:
 -there is an additional field exectime in  TASK_INFO, which can be set by
 rt_task_inquire and read in the info structure (the computation is slightly
 different for self and remote measurement);
 -xnthread_get_exectime() and xnthread_get_lastswitch() pass the values of the
 current thread's  timing out of xn;
 -exectime and lastswitch times are stored in an extended xnstat_runtime_t,
 updated by xnstat_runtime_update() (but not exactly like the total item)

That was not my idea, and there is a reason for it, see below.

 
 it has been tested (only on  P3 single core cpu) with the testexec program 
 also
 attached : there are 2 periodic tasks, clockit and loop, which measure
 either their exectime, or the one of the other task: the measures 
 seems reasonable, except when the clockit task measures itself, in that case 
 the
 first and second printed values are always absurd for a reason I cannot
 understand...)

A few generic wishes related to your patch:

 - Please don't include debug or commented out code in your patches.

 - Please avoid unrelated changes

 - Please use an editor that properly formats your code, e.g. doesn't
   insert spaces where tabs belong according to kernel style

 
 Only works in primary mode... (also I hope that the tsc is monotonic?)

Don't worry, TSC can be considered monotonic under Xenomai (that's why
you have to switch off frequency scaling e.g.).

 
 I have no idea of what may happen on a smp or when on the fly migrating tasks!

SMP should not be an issue, given that we rely on more or less
synchronised TSCs anyway.

...
 diff -urN xenomai-2.3.1-orig/include/nucleus/stat.h 
 xenomai-2.3.1/include/nucleus/stat.h
 --- xenomai-2.3.1-orig/include/nucleus/stat.h 2006-12-26 19:38:59.0 
 +0100
 +++ xenomai-2.3.1/include/nucleus/stat.h  2007-06-25 15:48:25.0 
 +0200
 @@ -31,6 +31,10 @@
  
   xnticks_t total; /* Accumulated execution time */
  
 + xnticks_t exectime; /* Overall execution time from taskspawn upto 
 lastswitch*/
 +
 + xnticks_t lastswitch; /* Last time the task was made active */
 +
  } xnstat_runtime_t;
  
  /* Return current date which can be passed to other xnstat services for
 @@ -42,6 +46,10 @@
  do { \
   (sched)-current_account-total += \
   start - (sched)-last_account_switch; \
 + (sched)-current_account-exectime += \
 +xnstat_runtime_now() - (sched)-last_account_switch; \
 + (sched)-current_account-lastswitch = \
 +xnstat_runtime_now(); \

My idea was to keep a persistent version the existing xnstat_runtime_t
instance in xnthread (and later on also xnintr). That one shall not be
reset on readout via /proc.

Instead, you establish quite some new calculations that break
the existing API (the switch date is given via start - which was
misnamed so far, I just changed it to date) and increase the runtime
overhead in the hotpath. Why? All the information you should need is
already there, it just has to be saved from being vaporised when the
user dumps /proc/xenomai/stat.

   (sched)-last_account_switch = start; \
  } while (0)
  

Let's try it like this: Change Xenomai so that it leaves the existing
xnthread_t::stat.account untouched when it reads /proc. Rather add
something like xnstat_runtime_t last; to xnthread_t::stat. On readout
for /proc output, do the stats now like account-last and then move
account into last. For your task exectime, you can then read
xnthread_t::stat.account directly, because it will always reflect the
full task history. Would't this work better?

Thanks for working on this!

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core