* [Xenomai-help] 0 CPU time problem
@ 2011-11-04 19:08 Tom Z
2011-11-04 19:21 ` Gilles Chanteperdrix
0 siblings, 1 reply; 7+ messages in thread
From: Tom Z @ 2011-11-04 19:08 UTC (permalink / raw)
To: xenomai@xenomai.org
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
Hi All,
I am trying to measure the CPU time consumed by a function foo(), and here is how I do it:
void foo(){
struct timespec tp1, tp2;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp);
//Computation goes here
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp2);
//The CPU time is given between the difference between tp2 and tp 1
}
The program is running on Ubuntu 10.10, and the kernel is 2.6.37 patched with Xenomai 2.5.6
Here is what I observed:
1) If foo() is running in the Linux domain (i.e., called by a regular Linux process), the CPU time obtained by the above method looks normal, and the mean CPU time of 25000 invocations of foo() is 10 ms.
2) If foo() is running in the primary domain (i.e., called by a Xenomai task spawned by rt_task_create() and rt_task_start()), then *most of the time*, the CPU time also looks as normal as the result in 1), and the mean CPU time is also about 10 ms. However, I also noticed that sometimes the CPU time obtained by the above method is 0. This zero value did not appear often, and out of 25000 invocations of foo(), I noticed that there is only 1 invocation of foo() where the CPU time is 0. BTW, the Xenomai task's priority is 99.
What causes this 0 CPU time in the primary domain? Is there something wrong with my method to measure the CPU time?
Thanks,
Tom
[-- Attachment #2: Type: text/html, Size: 2167 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Xenomai-help] 0 CPU time problem 2011-11-04 19:08 [Xenomai-help] 0 CPU time problem Tom Z @ 2011-11-04 19:21 ` Gilles Chanteperdrix 2011-11-04 21:03 ` Tom Z 0 siblings, 1 reply; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-11-04 19:21 UTC (permalink / raw) To: Tom Z; +Cc: xenomai@xenomai.org On 11/04/2011 08:08 PM, Tom Z wrote: > Hi All, > > I am trying to measure the CPU time consumed by a function foo(), and > here is how I do it: > > void foo(){ struct timespec tp1, tp2; > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp); > > //Computation goes here > > > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp2); //The CPU time is > given between the difference between tp2 and tp 1 > > } > > > The program is running on Ubuntu 10.10, and the kernel is 2.6.37 > patched with Xenomai 2.5.6 > > > Here is what I observed: > > 1) If foo() is running in the Linux domain (i.e., called by a regular > Linux process), the CPU time obtained by the above method looks > normal, and the mean CPU time of 25000 invocations of foo() is 10 > ms. > > 2) If foo() is running in the primary domain (i.e., called by a > Xenomai task spawned by rt_task_create() and rt_task_start()), then > *most of the time*, the CPU time also looks as normal as the result > in 1), and the mean CPU time is also about 10 ms. However, I also > noticed that sometimes the CPU time obtained by the above method is > 0. This zero value did not appear often, and out of 25000 invocations > of foo(), I noticed that there is only 1 invocation of foo() where > the CPU time is 0. BTW, the Xenomai task's priority is 99. > > What causes this 0 CPU time in the primary domain? Is there something > wrong with my method to measure the CPU time? We do not know what skin you use, we will assume that you use Xenomai posix skin, so, compile with the right flags. CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, so, clock_gettime probably returns an error, and the struct timespec is unchanged. If somehow the glibc clock_gettime is used, and this call does not cause a system call, then all bets are off, and even a lockup could happen. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] 0 CPU time problem 2011-11-04 19:21 ` Gilles Chanteperdrix @ 2011-11-04 21:03 ` Tom Z 2011-11-04 21:36 ` Gilles Chanteperdrix 0 siblings, 1 reply; 7+ messages in thread From: Tom Z @ 2011-11-04 21:03 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org [-- Attachment #1: Type: text/plain, Size: 3166 bytes --] "We do not know what skin you use, we will assume that you use Xenomaiposix skin, so, compile with the right flags." Here is how I build my program, say, fooTest: gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread -lnative -lrtdk fooTest.c -o fooTest "CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, so, clock_gettime probably returns an error, and the struct timespec is unchanged. If somehow the glibc clock_gettime is used, and this call does not cause a system call, then all bets are off, and even a lockup could happen." Thanks for explaining this. So can I trust the CPU time I obtained with my method when the function is running in the primary mode? It seems you explanation implies that the results I obtained are not reliable, if so, are there other reliable ways to obtain the CPU time? With many thanks, Tom ________________________________ From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> To: Tom Z <tomz30@domain.hid> Cc: "xenomai@xenomai.org" <xenomai-help@gna.org> Sent: Friday, 4 November 2011 2:21 PM Subject: Re: [Xenomai-help] 0 CPU time problem On 11/04/2011 08:08 PM, Tom Z wrote: > Hi All, > > I am trying to measure the CPU time consumed by a function foo(), and > here is how I do it: > > void foo(){ struct timespec tp1, tp2; > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp); > > //Computation goes here > > > clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp2); //The CPU time is > given between the difference between tp2 and tp 1 > > } > > > The program is running on Ubuntu 10.10, and the kernel is 2.6.37 > patched with Xenomai 2.5.6 > > > Here is what I observed: > > 1) If foo() is running in the Linux domain (i.e., called by a regular > Linux process), the CPU time obtained by the above method looks > normal, and the mean CPU time of 25000 invocations of foo() is 10 > ms. > > 2) If foo() is running in the primary domain (i.e., called by a > Xenomai task spawned by rt_task_create() and rt_task_start()), then > *most of the time*, the CPU time also looks as normal as the result > in 1), and the mean CPU time is also about 10 ms. However, I also > noticed that sometimes the CPU time obtained by the above method is > 0. This zero value did not appear often, and out of 25000 invocations > of foo(), I noticed that there is only 1 invocation of foo() where > the CPU time is 0. BTW, the Xenomai task's priority is 99. > > What causes this 0 CPU time in the primary domain? Is there something > wrong with my method to measure the CPU time? We do not know what skin you use, we will assume that you use Xenomai posix skin, so, compile with the right flags. CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, so, clock_gettime probably returns an error, and the struct timespec is unchanged. If somehow the glibc clock_gettime is used, and this call does not cause a system call, then all bets are off, and even a lockup could happen. -- Gilles. [-- Attachment #2: Type: text/html, Size: 4392 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] 0 CPU time problem 2011-11-04 21:03 ` Tom Z @ 2011-11-04 21:36 ` Gilles Chanteperdrix 2011-11-05 2:31 ` Tom Z 2011-11-05 11:27 ` Philippe Gerum 0 siblings, 2 replies; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-11-04 21:36 UTC (permalink / raw) To: Tom Z; +Cc: xenomai@xenomai.org On 11/04/2011 10:03 PM, Tom Z wrote: > > We do not know what skin you use, we will assume that you use > > Xenomai posix skin, so, compile with the right flags. > > Here is how I > build my program, say, fooTest: gcc -I/usr/xenomai/include > -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative > -L/usr/xenomai/lib -lxenomai -lpthread -lnative -lrtdk fooTest.c -o > fooTest You are using the native skin then. > > CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, > > so, clock_gettime probably returns an error, and the struct timespec > > is unchanged. If somehow the glibc clock_gettime is used, and this > > call does not cause a system call, then all bets are off, and even a > > lockup could happen. > > Thanks for explaining this. So can I trust the > CPU time I obtained with my method when the function is running in > the primary mode? It seems you explanation implies that the results I > obtained are not reliable, if so, are there other reliable ways to > obtain the CPU time? No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux kernel, so, it does not see the time spent in primary mode. If the foo function does not suspend, you can use rt_timer_tsc(), but the answer is no, there is currently no way to get the cpu time used when in primary mode. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] 0 CPU time problem 2011-11-04 21:36 ` Gilles Chanteperdrix @ 2011-11-05 2:31 ` Tom Z 2011-11-05 13:33 ` Gilles Chanteperdrix 2011-11-05 11:27 ` Philippe Gerum 1 sibling, 1 reply; 7+ messages in thread From: Tom Z @ 2011-11-05 2:31 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org [-- Attachment #1: Type: text/plain, Size: 2791 bytes --] Hi Gilles, "No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux kernel, so, it does not see the time spent in primary mode. If the foo function does not suspend, you can use rt_timer_tsc(), but the answer is no, there is currently no way to get the cpu time used when in primary mode." Thanks a lot for the explanation. It seems my understanding on how Xenomai works was incorrect. I thought that if a task, say, myRTTask() is spawned by rt_task_create() and rt_task_start(), then myRTTask() will always run in the primary mode, so if myRTTask() calls foo(), then foo() will be running in the primary mode all the time. The correct fact is, myRTTask() could be running in either the primary mode or the secondary mode, right? This arises my another question, if foo() uses some third party libraries (with source code available), how can I tell what parts of foo() will be running in the primary mode, and what parts will be in the secondary mode? Are there principles for deciding whether the code is in the primary mode or the secondary mode? Thanks again for your patient help. Tom ________________________________ From: Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> To: Tom Z <tomz30@domain.hid> Cc: "xenomai-help@domain.hid" <xenomai@xenomai.org> Sent: Friday, 4 November 2011 4:36 PM Subject: Re: [Xenomai-help] 0 CPU time problem On 11/04/2011 10:03 PM, Tom Z wrote: > > We do not know what skin you use, we will assume that you use > > Xenomai posix skin, so, compile with the right flags. > > Here is how I > build my program, say, fooTest: gcc -I/usr/xenomai/include > -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative > -L/usr/xenomai/lib -lxenomai -lpthread -lnative -lrtdk fooTest.c -o > fooTest You are using the native skin then. > > CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, > > so, clock_gettime probably returns an error, and the struct timespec > > is unchanged. If somehow the glibc clock_gettime is used, and this > > call does not cause a system call, then all bets are off, and even a > > lockup could happen. > > Thanks for explaining this. So can I trust the > CPU time I obtained with my method when the function is running in > the primary mode? It seems you explanation implies that the results I > obtained are not reliable, if so, are there other reliable ways to > obtain the CPU time? No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux kernel, so, it does not see the time spent in primary mode. If the foo function does not suspend, you can use rt_timer_tsc(), but the answer is no, there is currently no way to get the cpu time used when in primary mode. -- Gilles. [-- Attachment #2: Type: text/html, Size: 3811 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] 0 CPU time problem 2011-11-05 2:31 ` Tom Z @ 2011-11-05 13:33 ` Gilles Chanteperdrix 0 siblings, 0 replies; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-11-05 13:33 UTC (permalink / raw) To: Tom Z; +Cc: xenomai@xenomai.org On 11/05/2011 03:31 AM, Tom Z wrote: > Hi Gilles, > > > No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux > > kernel, so, it does not see the time spent in primary mode. If the > > foo function does not suspend, you can use rt_timer_tsc(), but the > > answer is no, there is currently no way to get the cpu time used > > when in primary mode. > > Thanks a lot for the explanation. It seems my understanding on how > Xenomai works was incorrect. I thought that if a task, say, > myRTTask() is spawned by rt_task_create() and rt_task_start(), then > myRTTask() will always run in the primary mode, so if myRTTask() > calls foo(), then foo() will be running in the primary mode all the > time. The correct fact is, myRTTask() could be running in either the > primary mode or the secondary mode, right? This arises my another > question, if foo() uses some third party libraries (with source code > available), how can I tell what parts of foo() will be running in the > primary mode, and what parts will be in the secondary mode? Are there > principles for deciding whether the code is in the primary mode or > the secondary mode? Hi, it would be nice if you could quote and wrap mails as is usual on public mailing lists. Every Linux system call causes a switch to secondary mode, as well as every call to a xenomai system call documented as such. For instance, if you look at rt_queue_create documentation, you see: Environments: This service can be called from: * Kernel module initialization/cleanup code * User-space task (switches to secondary mode) If you want to detect unwanted mode switches to secondary mode, you can use rt_task_set_mode with the T_WARNSW bit, as is demonstrated in the example: examples/native/sigdebug.c in xenomai sources tree. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] 0 CPU time problem 2011-11-04 21:36 ` Gilles Chanteperdrix 2011-11-05 2:31 ` Tom Z @ 2011-11-05 11:27 ` Philippe Gerum 1 sibling, 0 replies; 7+ messages in thread From: Philippe Gerum @ 2011-11-05 11:27 UTC (permalink / raw) To: xenomai, tomz30 On 11/04/2011 10:36 PM, Gilles Chanteperdrix wrote: > On 11/04/2011 10:03 PM, Tom Z wrote: >>> We do not know what skin you use, we will assume that you use >>> Xenomai posix skin, so, compile with the right flags. >> >> Here is how I >> build my program, say, fooTest: gcc -I/usr/xenomai/include >> -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative >> -L/usr/xenomai/lib -lxenomai -lpthread -lnative -lrtdk fooTest.c -o >> fooTest > > You are using the native skin then. > >>> CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, >>> so, clock_gettime probably returns an error, and the struct timespec >>> is unchanged. If somehow the glibc clock_gettime is used, and this >>> call does not cause a system call, then all bets are off, and even a >>> lockup could happen. >> >> Thanks for explaining this. So can I trust the >> CPU time I obtained with my method when the function is running in >> the primary mode? It seems you explanation implies that the results I >> obtained are not reliable, if so, are there other reliable ways to >> obtain the CPU time? > > No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux kernel, > so, it does not see the time spent in primary mode. If the foo function > does not suspend, you can use rt_timer_tsc(), but the answer is no, > there is currently no way to get the cpu time used when in primary mode. > There is one, but deeply buried in the API basement, via rt_task_inquire(): RT_TASK_INFO info; RTIME start; ret = rt_task_inquire(NULL, &info); /* NULL means current task */ if (ret) goto Houston_handles_the_problem; start = info.exectime; ... do work .... ret = rt_task_inquire(NULL, &info); delta = info.exectime - start; /* elapsed CPU time in ns */ rt_task_inquire() will beget a syscall each time invoked though, so it does have some overhead. You need CONFIG_XENO_OPT_STATS enabled in your Kconfig for this feature (defaults to on). -- Philippe. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-11-05 13:33 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-04 19:08 [Xenomai-help] 0 CPU time problem Tom Z 2011-11-04 19:21 ` Gilles Chanteperdrix 2011-11-04 21:03 ` Tom Z 2011-11-04 21:36 ` Gilles Chanteperdrix 2011-11-05 2:31 ` Tom Z 2011-11-05 13:33 ` Gilles Chanteperdrix 2011-11-05 11:27 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.